IT — сфера большая и многогранная. В ней обитают программисты и сетевики, сисадмины и инженеры. Иногда попадаются копирайтеры, дизайнеры и маркетологи. Но это не точно.

Кто-то ушел в «компьютерную» профессию осознанно: сначала радиокружок, потом — технический факультет ВУЗа. Кто-то стал айтишником и вовсе по воле случая.

С точки зрения обывателя каждый «технарь» обязан как минимум чинить компьютеры любого вида и возраста. И уж точно понимать в программировании. Как раз о последнем мы и хотели бы поговорить: насколько важны кодерские навыки ИТ-спецам, не занятым непосредственно разработкой?

Мы поделимся с вами историями двоих наших коллег из отдела DevOps. Оба они в какой-то момент интересовались языками программирования, однако пошли по другому пути. Это тенденция, заговор или несчастный случай? Как и почему это случилось? Ответы под катом!

Илья, инженер информационных систем

Всем привет. Если честно, вопрос неожиданный. Сложно сказать, в какой именно момент я предпочел программированию работу в DevOps’е. Наверное, это предрасположенность, а не какой-то осознанный выбор. Давайте расскажу по порядку.

Компьютера в нашей семье изначально не было. Все-таки, девяностые, а это дорогое удовольствие. Зато я дружил с одним мальчишкой из «профессорской семьи». У них дома стоял невиданный по тем временам 486-ой. Часами мы сидели у экрана, рубились в разные игры. А когда мощностей перестало хватать, даже что-то апгрейдили. Вроде бы, расширяли память, точно уже не вспомню.

Спустя пару лет в нашей семье тоже появился компьютер. По-моему, это был 133 Pentium. Я читал на нем книжки, играл. Но хотелось чего-то большего. Не только пользоваться компьютером, но и создавать. Вместе с тем самым другом мы записались на курсы программирования. Изучали BASIC, Pascal, Assembler под x86. Могу сказать, что наличие домашнего компьютера очень способствовало обучению.

На курсах мы обычно решали логические задачки, делали примитивные игры. Мне очень запомнилась «Змейка»: сначала мы её написали, а потом долго играли по очереди, все вместе. Баловство, конечно, но было здорово и весело. Еще одну программу мы написали с другом Димой: чат по COM-порту.

Со временем Pascal и Assembler отпали сами собой. В большинстве современных задач они мало применимы. Если ты, конечно, не крутой низкоуровневый разработчик. Но такими, мне кажется, люди именно рождаются. Я не из их числа. :)

По ходу жизни я так или иначе соприкасался с кодингом. Например, знание BASIC мне пригодилось во время службы в армии. У нас, как и в любой другой части, были караулы. Перед заступлением на пост приходилось готовить огромную кипу бумаг: кто заступает, когда, на какую именно «должность». Я решил этот процесс автоматизировать. С разрешения офицеров написал программку на VBA: в базу данных Access «забивался» личный состав. Потом через мое приложение всё это связывалось с «рыбами» Word’овских документов, и весь пакет автоматически готовился и отправлялся на печать. Нужно было только прокликать людей и «поставить» их на нужную должность. Удобно получилось.

Следующий язык, который заинтересовал меня, — PHP. Я работал тогда в одном хостинг-провайдере, в техподдержке. Мне выпадали и ночные, и дневные смены в офисе. Если тикетов было мало, я мог взять с полки книжку по программированию и провести время с пользой. Помню, однажды ночью мой взгляд упал на 600-страничный талмуд по Perl. Мне язык понравился, я изучил его на достаточно неплохом уровне. Плагин для биллинга, к примеру, на нем написал.

Вообще, если говорить о программировании, мне всегда был ближе скриптовый подход: программа, которая выполняет какое-то действие в рамках моих рабочих нужд. Поэтому с C++, Go и другими языками, с помощью которых пишутся комплексные программы, у меня не сложилось. Но прочитать и понять логику работы кода я более чем в состоянии.

Наверное, всё это в совокупности и привело меня в работу DevOps’ом. Я работал в поддержке софтовой компании и видел, как страдают разработчики. Хотелось как-то облегчить им жизнь. Чтобы было проще поддерживать код, настраивать серверы. Когда всё грамотно сконфигурировано, голова болит гораздо меньше. Но заниматься именно разработкой я как-то перехотел. :)

В ISPsystem, в моем текущем отделе, языком «по умолчанию» был уже Python. Проблем с его изучением у меня не возникло. Во-первых, когда есть некий кодерский бэкграунд, новые языки учить попроще. Во-вторых, коллеги быстро помогли мне втянуться. Ну и bash, конечно. Без него, по-моему, ни один Linux-администратор не обходится. Собственно, Python и bash — это и есть мой активный стек, не считая Git, YAML и тому подобного.

На Python у нас написаны почти все внутренние сервисы, на bash — скрипты. Я занимаюсь поддержкой внутренней инфраструктуры: офисные серверы, серверы для разработчиков, сети, внутренние инструменты (GitLab, YouTrack) и т.д.

Иногда приходится залезать в код разработчика, чтобы понять, что пошло не по плану. Раньше все было на C++ — приходилось звать программистов, просить объяснить. А вообще, когда работаешь в поддержке, регулярно ходишь к разработчикам, спрашиваешь, смотришь, как они общаются с кодом, потихоньку учишься. Гуру, конечно, не стать, но как минимум спокойно читать и понимать код начинаешь.

Возвращаясь к рабочим моментам, Python — это как швейцарский нож и для программистов, и для администраторов. Много готовых модулей для работы с «модными-актуальными» вещами: Kubernetes, Docker, GitLab, обработкой YAML-файлов, JSON…

Кстати, помню, еще в школе я выписывал журнал, который назывался «Linux Format». К номерам прилагались диски: сначала обычные, потом DVD. Меня однажды очень впечатлил разворот с переводом статьи от автора Python. Он рассказывал, как хорош язык, что за ним будущее. Прошли годы — практика показывает, что он не ошибся.

В целом, я не представляю себе хорошего админа без навыков программирования, хотя бы на уровне написания простых скриптов. Часто можно автоматизировать рутину со множеством однотипных действий или обработкой входных данных. Нужно понимать, как работают циклы, условные операторы. Linux-администратору, как минимум, еще нужен bash. Windows-администратору — PowerShell.

Что касается неизбежных служебных параллелей и сравнений DevOps’ов с разработчиками — пожалуй, закрою этот вопрос сразу. Под долгу службы я занимаюсь «установкой» серверов с нуля, готовлю ОС, решаю всевозможные попутные проблемы, связанные с оборудованием, подключаю новые серверы во внутреннюю «серую» сеть и т.п. Кроме того, все сервера 24/7 находятся под мониторингом и регулярно бэкапятся. Непосредственно программисты этим не занимаются. Более того, у них нет доступа к подобным задачам и настройкам.

При этом наши разработчики — товарищи весьма прошаренные и грамотные. Могут, например, на GitLab’е накидать простенький CI/CD-скрипт. Но если у них что-то не получается, мы открываем их CI/CD и правим. Или добавляем необходимые доступы. 

При этом я не могу сказать, что считаю себя «круче» разработчиков. У каждого сотрудника должен быть свой профиль, своя сфера ответственности. Грубо говоря: есть какая-то новая технология, с которой в компании никто не сталкивался. Если программист начнет с ней разбираться, ему придется потратить (условно) 10 часов рабочего времени. А мы как уже опытные ребята потратим всего 2 часа и потом сможем всё настроить и рассказать коллегам, как работать с технологией. 

Думаю, я пошел в DevOps еще отчасти потому, что мне нравится разбираться со сложными вещами. Я умею быстро решать проблемы и объяснять людям, как пользоваться чем-то сложным просто.

Анатолий, релиз-инженер

В универе я учился по специальности «АСУ ТП» — автоматизированные системы управления технологическим процессом. Это уже достаточно близко к DevOps. А со второго курса устроился системным администратором в научно-техническом центре. В числе прочего — переносил весьма развесистую инфраструктуру с FreeBSD Jail на систему виртуализации Proxmox. Выходит так, что я попал в DevOps по самому популярному пути — из «сисадминства».

Программированием я увлекался еще в школе: на информатике нам давали BASIC и JS. В вузе в качестве дипломного проекта я разработал мобильное приложение на Java и Objective C.

Но после ВУЗа, окончательно взвесив все «за» и «против», я предпочел путь DevOps’а. Это был единственный способ совмещать работу в нескольких проектах. Что греха таить — хотелось не только работать, но и зарабатывать.

Со временем я понял, что DevOps — это еще и весьма увлекательная профессия. По крайней мере, гораздо менее однообразная, чем бэкенд. Фактически, мне приходится лавировать между непосредственно operations и development, а также отделами QA и техподдержкой.

DevOps-специалисту необходимо иметь широкий технический кругозор для принятия всесторонне взвешенных решений. Уметь смотреть на продукт с разных точек зрения. Например, с позиции бизнеса, которому предстоит оплачивать облачную инфраструктуру, с позиции дежурного инженера, которому ночью может «прилететь» алерт, и так далее.

Моя текущая должность в компании — релиз-инженер. Я координирую с разработчиками выпуск плановых релизов и багфиксов по обращениям в техподдержку. Ответствен за то, чтобы продукт был готов к выходу в релиз.

К примеру, я проверяю, что разработчики сформировали changelog, технические писатели его промодерировали, а переводчики перевели все интерфейсные сообщения на поддерживаемые языки. 

Кроме того, я сотрудничаю с разработчиками и строю пайплайны для автоматизированного тестирования и деплоя. А если встает задача перенести legacy-пайплайны из Jenkins в Gitlab CI, мне необходимо учесть привычки разработчиков и тестировщиков, которые будут ими пользоваться.

Я редко пишу код, но периодически требуются небольшие скрипты. Если раньше стэк был широким, от Groovy до R-lang — для анализа и визуализации логов, то сейчас это Python, на нем решаются 99% задач по автоматизации.

В заключение скажу, что для успешного старта в DevOps опыт классического системного администрирования нужней, нежели навыки разработчика, тестировщика или специалиста технической поддержки. Однако, даже если считать DevOps своего рода «ребрендингом» системного администрирования, для эволюционного перехода в него потребуется немножко стать программистом. Так, системному администратору, тестировщику, техсаппорту для работы в небольшой компании, скорее всего, хватит навыков bash и умения гуглить. Но чтобы расти дальше, нужно стремиться учиться кодить.