Привет, я Сергей, техлид банка «Центр-инвест» и один из авторов курса «DevOps для эксплуатации и разработки». Раньше занимался написанием бэкендов на Java и Kotlin для финтех-энтерпрайза, потом занялся архитектурой, выстраиванием процессов и залез в DevOps. Заношу DevOps-практики, техлижу и деврелю.
В этой статье я расскажу:
Почему DevOps — это круто и нужно;
С чего начать свой путь в DevOps;
Кто такой T-shape-специалист;
Как мыслят истинные инженеры;
Что почитать, куда сходить и на что посмотреть.
Зачем нужен DevOps
Всё, что ни делается, — делается либо ради бизнеса, либо ради людей, либо ради того и другого. При этом есть вещи, которые не приносят ценности никому. Это могут быть:
ошибки в коде,
ошибки при ручном развертывании сервисов,
долгое выяснение проблем на продуктиве,
всяческая грустная рутинная работа, которой можно избежать.
Процесс должен быть максимально удобным и автоматизированным, а рутина и другие вещи, не приносящие бизнесу ценности, должны быть сведены до минимума. Так и возник DevOps! Вернее, сам термин возник позже — он был предложен Патриком Дюбуа. Но сама идея выстраивания и автоматизации процессов совсем не нова.
Исторически сложилось так, что во многих компаниях есть отделы, и порой коммуникационные связи между разными отделами не самые адекватные: «Мы, админы, делаем своё дело, а вы, разработчики, делаете своё». При этом клиенту ведь всё равно, из-за кого не работает приложение — из-за админов или из-за разработчиков. Поэтому очень важно, чтобы все выпускающие продукт были заинтересованы в общем деле, а не только в своем кусочке.
Качественный и крутой продукт — это продукт с хорошей поддержкой, безопасностью, быстрой поставкой фич. Со временем практики улучшения продукта начали вырисовываться и превратились в целую культуру — культуру DevOps. DevOps — это про то, как наносить пользу и причинять радость.
Хотите увидеть DevOps в реальной жизни? Сгоняйте в Москве в ресторан «Старик и море». Там нет официантов, но процессы настолько отлажены, что очень вкусную еду ты получаешь максимально быстро и по мере готовности — вот она, непрерывная поставка!
И разве не хочется сделать то же самое на своей работе?! И не важно: администратор вы или разработчик. Ведь насколько круто, когда по нажатию кнопки запускается конвейер сборки и доставки продукта (пайплайн), в процессе которого код тестируется на качество и безопасность, а после доставляется до продуктива и радует клиентов.
Инструменты и реализация DevOps-практик
Чтобы претворить практики в жизнь, возникли инструменты. Инструменты помогают в поставке приложений, тестировании, проверке безопасности, мониторинге системы и другом — их настолько много, что глаза разбегаются! Только посмотрите: https://landscape.cncf.io/
Инженеры очень любят разные инструменты, но любой инструмент всегда должен быть рационально оправдан — нельзя брать инструмент ради инструмента. Нельзя вестись на карго-культ: то, что подходит одной компании, может совершенно не подойти вашей. Например, нельзя взять и занести Kubernetes ради Kubernetes’а только потому, что он модный. Если у вас маленькая команда или нет достаточной экспертизы в Кубере — возьмите Swarm.
Хороший инженер должен мыслить не в вакууме, а понимать, что бизнесу важен time-to-market, эксплуатации важно уметь поддерживать этот инструмент, а безопасникам важно, чтобы безопасность была безопасной. В общем, всегда нужно стремиться смотреть на вещи со всех сторон, выстраивая полную картину. Более того, хороший инженер должен следить за трендами в индустрии, чтобы понимать, куда она двигается. Для этого нужно ходить по конференциям, посматривать на такие отчеты, как State of DevOps, Technology Radar.
Как ворваться в DevOps
Как правило, в DevOps приходят либо с разработки, либо с эксплуатации, хотя бывает и с инфобеза — то есть в DevOps человек идет с какими-то базовыми знаниями.
Двигаться с нуля туда тоже возможно, но просто придётся пройти путь длиннее. Но, если вы идёте в профессию только ради денег или потому что это модно, думаю, ваш путь обречён на провал. Это не только про DevOps — это про любую работу. Как бы это банально ни было, но работа должна вам нравиться, приносить что-то интересное, развивать вас и мотивировать. Зачем страдать?
Если вам нравится докапываться до сути вещей, нравятся инженерные задачи, а в детстве вы разбирали куклу барби, то вы на верном пути!
Если вы администратор и не знаете верхнеуровневый язык программирования, а знаете только баш, — начните изучать язык, который чаще всего востребован в вашей компании. Если вы разработчик — начните разбираться в Линуксе. Если ни то ни другое — просто начните!
Истинный инженер всегда пытается разобраться во всём и всё улучшить. Если вы уже работаете в компании, постарайтесь сделать что-то, что избавит вас и ваших коллег от рутины. Например, если коллеги вручную выгружают что-то из базы данных, напишите скрипт, который будет делать это автоматически. Естественно, главное — всё проверять и делать осознанно, чтобы случайно не навредить.
Очень важно понимать, что прошло время, когда разработчик или системный администратор могут быть в вакууме. Если разработчик не понимает инфраструктуру, в которой работает его код, — это плохо. Равно как и админ, который не понимает, что он задеплоил.
Разумеется, всё знать нельзя, и какое-то знание может быть основным, а какие-то — смежными. Кстати, есть такой термин T-shape-инженер — как раз про это. Вертикальная палочка в букве Т — это ваш главный скил, а черта сверху — смежные. Шутят ещё, что нужно много что знать, — больше похоже на Ж-shape. В общем, как раз из таких T-shape’ов и вырастают DevOps-специалисты.
Чтобы посмотреть на возможные пути развития DevOps-специалиста, можно глянуть в этот роадмап: https://roadmap.sh/devops
Очень важно развивать софт-скилы, общаться с другими специалистами, выступать на митапах, конференциях. Инженер должен уметь доносить мысли: прошли те времена, когда в IT можно было быть социофобом. Про это я ещё скажу чуть ниже.
DevOps — это методология и культура, DevOps — это не человек. Но именно грамотные инженеры претворяют практики DevOps’а в жизнь и масштабируют их на всю организацию.
Кстати, есть классная мотивирующая книжка про инженерные истории — 97 Things Every SRE Should Know, Emil Stolarsky and Jaime Woo. Сам термин SRE (Site Reliability Engineering) — это про то, как реализовывать DevOps-практики, обеспечивая бесперебойную работу сервисов, сделать поведение системы понятным, надежным и качественным.
В этой книге меня очень зацепила история от самого автора. Это история о том, как в ракету «Аполлон» дважды ударила молния. Вот какая вероятность, что такое вообще могло произойти: что ударит молния, да ещё и дважды?!
В общем, в ракете с экранов пропали метрики, и дашборды превратились в тыквы. Астронавты в панике: что делать?! Они давай звонить в центр управления полётов. Те тоже в шоке, не знают — такого нет в инструкциях. И тут некий Джон Аарон говорит, мол, переключите там какой-то тумблер туда и туда. Команда в шоке, НАСА в шоке: что за тумблер — непонятно. Аарон им всё объяснил, метрики снова отросли, ракета спасена. Потом его спрашивают: «А как?»
Он рассказал, что как-то возился на тренажёре такой ракеты, и там внезапно с экранов пропали метрики. Вместо того, чтобы по классике выключить и снова включить, он решил разобраться и привести систему в штатное состояние — именно тогда он и обнаружил решение, которое спасло ракету.
Отличная история, мне она прямо нравится. Она показывает, что инженер всегда докопается до сути.
Или вот история не из книги: давно, когда интернет был медленным, каким-то ребятам нужно было схему передать по интернету. А там картинка, она никак не передавалась — интернет вообще медленный был. А что они сделали? Они взяли её максимально сжали, запаковали. Позвонили по телефону и продиктовали просто по байтам. На другой стороне всё записали и распаковали картинку. Беспроводной интернет!
Истинный инженер всегда что-то придумает!
Выводы и полезности
Для полноценного развития в грамотного инженера необходимо брать знания из разных источников. Нельзя стать DevOps-специалистом, только прочитав книжки или пройдя курсы. Нужно пользоваться всем, чем только можно: сообществами, книгами, конференциями, митапами, практикой на работе.
Так что развивайтесь, наносите добро и причиняйте пользу с помощью DevOps-практик!
Вот немного полезностей:
Книга «Руководство по DevOps. Как добиться гибкости, надежности и безопасности
мирового уровня в технологических компаниях», Джон УиллисКнига «Проект „Феникс“. Роман о том, как DevOps меняет бизнес к лучшему», Джин Ким, Джордж Спаффорд, Кевин Бер
Книга «Ускоряйся! Наука DevOps: Как создавать и масштабировать высокопроизводительные цифровые организации», Форсгрен Николь, Хамбл Джез
Курс «DevOps для эксплуатации и разработки» Яндекс Практикума
Конференция DevOops. Кстати, она совсем скоро, а промокод SergeySabbath даёт скидку 25% на билет для частных лиц.
Роадмап DevOps-специалиста: https://roadmap.sh/devops
