DevOps. Мы не кормим медведей!
Дай человеку рыбу, и он будет сыт один день. Дай человеку удочку, и он будет сыт всю жизнь.
Привет! Меня зовут Николай Лотоцкий, я — DevOps Evangelist в Namecheap, Inc. В IT более 15 лет. В этой статье я расскажу о процессе образования команд и их инфраструктуре с использованием методологий DevOps.
Почему сейчас именно DevOps?
Где-то полтора года назад я задумался над тем, как можно что-то написать, не зная, где это все будет размещаться. И тогда я впервые познакомился с философией DevOps. С тех пор не представляю себе процесс разработки без практик и методологий DevOps. Пропагандирую их на родной фирме. Делаю, по моему мнению, жизнь других легче и лучше.
Многие до сих пор рассматривают DevOps не как философию, а как роли в проектах. Это приводит к тому, что инфраструктурой начинают заниматься выделенные сотрудники, а не инфраструктурные команды. Потом, когда обнаруживается, что в разных командах такие сотрудники работают, как лебедь, рак и щука, этих людей постфактум сводят в инфраструктурные команды, призванные улучшать инфраструктуру в рамках целой компании. Однако и тут оказывается все гладко, так как частные запросы от команд возвращают нас к прежнему статус-кво, поскольку люди в команде начинают все так же работать над частными проблемами, не сосредотачиваясь на инфраструктурных изменениях в рамках компании. В итоге получается операционный тупик. О том, как решить такую проблему и почему одной из DevOps-практик является образование команд, и рассказывается в этой статье.
Мы не кормим медведей! Почему? Мишки же такие пушистые и красивые! Однако так может сказать только тот, кто не знает, что человек, встретивший этого зверя в тайге, скорее всего, там и останется. Особенно если он решит оставить косолапому лакомство у своей палатки.
К чему это я? В инфраструктурных командах девелоперов очень часто начинают «подкармливать». «Как это?» — спросите вы. «А вот так! — отвечу вам я.
Разберем для простоты изложения некоторые ручные кейсы
Замечу, что я слышал об IaaS и как инженер являюсь ее евангелистом. Допустим, инженеру-разработчику Алексею понадобилось внести в свой проект инфраструктурное изменение. Скажем, сменить тип хранилища с S3 Standart на Glacier. Алексей идет в инфраструктурную команду, отвлекает тамошнего инженера Кирилла от его работы над миграциями других команд из дата-центра в облако и успешно рапортует о проделанной работе.
Вот Алексей и является типичным «медведем», который, атаковав Кирилла, выманил у него «пачку печенья» или «горсть орехов» и, гордый, ушел в тайгу. Казалось бы, в этом нет ничего криминального.
Раз за разом Алексей обращается к Кириллу с подобными просьбами. А что Кирилл? Ну ему оказать Алексею услугу несложно, да и с хорошим человеком не хочется портить отношения.
Однажды Алексею понадобилось перевести на новые типы 200 хранилищ, причем сделать это избирательно, проводя анализ периодичности доступов к данным на них. И опять он пошел к Кириллу! А тот в это время имел нагрузку, связанную с DDoS-атакой на серверы. В результате на указанную просьбу дал вежливый отказ. Понятное дело, Алексей обиделся: зачем тогда, по его мнению, в компании инфраструктурная команда, да еще и с такими неинтеллигентными личностями.
С чем мы тут имеем дело? С типичной прикормкой «медведя» Кириллом. Раз за разом «косолапый» ходил на одно и то же прикормленное место. Возможно, даже отпугивая других «мишек». Пока не встретил отказ.
Ситуация типичная. Инфраструктурные команды часто не в силах ответить на все подобные запросы. Останавливаются запланированные работы. Как быть? Что делать? Кто виноват? Как решить проблему чрезмерной загруженности оперативной работой инфраструктурной команды?
На мой взгляд, действовать в таких ситуациях нужно комплексно. И первое, что следует сделать, это назначить ответственного за «кормление медведей», некоего дежурного, в обязанности которого будут входить ответы на вопросы, выполнение простых заявок команд и консультирование их по тем или иным пунктам.
Какие вопросы будут в ведении этого дежурного?
Он будет:
- помогать в решении простых и горящих задач;
- участвовать в составлении запросов к инфраструктурной команде. Да-да, вы не ослышались: часто девелоперские команды не знают, что хотят от инфраструктурных, разговаривают с ними на разных языках, и просто нуждаются в переводчике с «девелоперского» на «инфраструктурный»;
- собирать базу знаний типовых вопросов, чтобы в будущем по ней можно было составить гайд для ответов типа «А вы пробовали включить/выключить компьютер?».
Дежурный станет некой плотиной между вами и «медведями».
Будем считать, что отчасти мы купировали проблему «кормежки медведей». Однако, хоть и купированная, сама проблема осталась. «Медведи» все равно продолжат к вам ходить, отгрызая у вас драгоценные человеко-часы, которые можно было бы потратить на глобальные инфраструктурные изменения.
В DevOps-практиках часто пренебрегают обучением, хотя оно является одним из главнейших столпов DevOps-философии. Персонал надо учить, чтобы не делать потом самому. Надо учить, чтобы не приходилось расхлебывать последствия. Надо учить, чтобы создавать костяк инфраструктурной команды на будущее.
Как выстроить процесс обучения?
Во-первых, в командах разработчиков стоит отобрать желающих заниматься инфраструктурой.
Во-вторых, среди этих желающих провести опросы. Для чего это делается? Все знают, что скорость каравана равна скорости самого медленного в нем верблюда. Точно так же и тут, основную скрипку будут задавать люди с самым низким пониманием. Входящие опросы необходимы и для того, чтобы вы имели представление об уровне группы, с которой вам предстоит работать.
В-третьих, составить базовый курс по технологиям и инструментам, с которыми вам приходится иметь дело.
В-четвертых, членам инфраструктурной команды провести ликбезы по тем технологиям, с которыми сталкиваются Dev-команды. Напишите джентльменский набор команд, правил, сборник советов и т. д.
Теперь поговорим о принципах подготовки базового курса:
- Курс не должен быть перегружен. Вы не обучаете нового члена инфраструктурной команды — вы готовите человека, который разделяет DevOps-философию и который будет забирать у вас операционную работу. Кстати, первую лекцию в начале курса посвятите именно философии DevOps, а не инструментам и практикам.
- Курс должен содержать информацию ТОЛЬКО ОБ ИСПОЛЬЗУЕМЫХ инструментах и практиках, не пытайтесь рассказывать о прекрасном далеко: это все забудется. Лучше сосредоточиться на том, что уже есть.
- Не углубляйтесь в дебри теории и практики, помните: человек не обязан знать больше того, с чем он встречается при исполнении своих повседневных обязанностей; он не должен уметь развертывать кластер ECS, а вот справляться с созданием сервиса и TaskDefinition обязан.
- При составлении курса надо давать базис, для того чтобы человек, столкнувшись с проблемой, мог хотя бы правильно подобрать слова для Google, а также для внятного вам ее объяснения без жестикуляции руками.
- Курс должен содержать накопленные вами рецепты для решения тривиальных задач.
- Курс не должен быть сверхсложным. Это ни к чему. Материал, на изложение которого у вас уйдет 90% времени, забудется от силы через неделю.
- Делайте упор на практике: теорию люди выучат потом, если будут копать глубже.
- По теории. Давайте ее маленькими порциями, и только самое необходимое. Да, понять, как что работает, важно, но также важно освоить инструмент!
После всего вышеперечисленного вы избавитесь от большого объема оперативной работы.
Напоследок отмечу, что такие практики успешно внедрены и работают в компании Namecheap, Inc. уже на протяжении года. Да, мы все еще «кормим медведей», но делаем это осознанно. Ну или если медведь нам просто не оставляет другого выбора :)
P. S. Все совпадения с реальными событиями, людьми или животными непреднамеренны и случайны.
