Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

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. Все совпадения с реальными событиями, людьми или животными непреднамеренны и случайны.

LinkedIn

26 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Ваш пример с DevOps, напомнил мне произведение К. Чапека «Война с саламандрами». Как капитан Ван Тох обучал саламандр, вот это эффективный DevOps =).

Стаття дуже товстий трогінг. Уявість собі що оптимальний теоретичний кейс — нічого не робити з процесами, просто почекати поки розвантажиться команда і все, а неоптимальний, який примножить хаос, додасть купу бузглуздої роботи купі людей, створить слабке місце в особі посередника і перетворить спілкування в поламаний телефон, якраз той що пропонується. Хто буде тою людиною, яка скаже — нічого не міняти в процесах і просто почекати оптимально? DevOps це про те що Dev і Ops не розділяються посередниками.

И первое, что следует сделать, это назначить ответственного за «кормление медведей», некоего дежурного, в обязанности которого будут входить ответы на вопросы, выполнение простых заявок команд и консультирование их по тем или иным пунктам.

складывается впечатление, что вы заново велосипед изобретаете, в виде давно устаревшего ITIL, вместо DevOps, просто потому что не знакомы ни с одной из этих методологий

а что мешает инфраструкурной команде работать через тикеты? нужно девелоперу/QA что-то — создал тикет. далее лид команды определяет кому этот тикет реализовать, в зависимости от загруженности и приоритетов.

Инфраструктурная команда и работает через тикеты. Однако часто надо говорить — твой тикет не приоритетный, мы сосредоточены сейчас на другой более важной и глобальной работе

Так а как это всё происходит?
Везде ж говорится что devops’ы являются частью команды разработки (ну или как минимум плотно работают сообща) и помогают в выборе инструментов/технологий, доставки кода, инфраструктурных решений. Зная все требования решаемой задачи (предпологаемые объёмы, нагрузку и т.д.)

А если девы пишут тикеты — поднимите redis (хотя может лучше что-то другое использовать) или сами там себе начали использовать google storage, когда остальной стек на aws, а devops’ы у вас понятия не имеют зачем это нужно и вообще какие там решения принимает dev-team.

Так да, просто тикет тикету рознь. У нас например есть отдельный джира проект для быстрых maintinience тасок. Он на канбане, и изменения которые требуют полчаса работы или всякий траблшутинг дейли активностей идёт в этот проект. Но если разработчик пишет что-то вроде «мы выпустили новый компонент, вот наша репа, внедрите его в сиай», а там работы на несколько дней, включая написания хелм чарта, изменения в dsl дженкинса, подготовка документации итд, то мы говорим «сори чувак, создавайте тикет в основном проекте». А основной джира проект уже на скраме, и там с этой таской уже будет обсуждение включать ли ее в текущий спринт или в следующий, создание сабтасков, назначение исполнителей, эстимация итд итп.
В целом получается что один два человека постоянно работают с мейнтиненс проектом (с ротацией в пару недель), остальные заняты проектной работой.

У нас этим девелоперы занимаются. Они могут выполнять все девопсовские задачи в дев/QA (кроме продакшена). Может надо отдать им часть полномочий?

На мой взгляд, действовать в таких ситуациях нужно комплексно. И первое, что следует сделать, это назначить ответственного за «кормление медведей», некоего дежурного, в обязанности которого будут входить ответы на вопросы, выполнение простых заявок команд и консультирование их по тем или иным пунктам.
Он будет:

помогать в решении простых и горящих задач;
участвовать в составлении запросов к инфраструктурной команде. Да-да, вы не ослышались: часто девелоперские команды не знают, что хотят от инфраструктурных, разговаривают с ними на разных языках, и просто нуждаются в переводчике с «девелоперского» на «инфраструктурный»;
собирать базу знаний типовых вопросов, чтобы в будущем по ней можно было составить гайд для ответов типа «А вы пробовали включить/выключить компьютер?».
Дежурный станет некой плотиной между вами и «медведями».

Чем это отличается от обычного L1/L2/L3 support ?
Добавьте сверху еще планирования, SLA и др. бизнес процессов и получите штуку еще более похожую на ITIL

В L1/L2/L3 нету места обучению — их задача решать проблемы. Я же пытался донести, что по итогу надо учить команды, дабы в будущем снизить количество обращений в L1/L2/L3

а самообучению место есть?

Однажды Алексею понадобилось перевести на новые типы 200 хранилищ, причем сделать это избирательно, проводя анализ периодичности доступов к данным на них. И опять он пошел к Кириллу! А тот в это время имел нагрузку, связанную с DDoS-атакой на серверы. В результате на указанную просьбу дал вежливый отказ. Понятное дело, Алексей обиделся: зачем тогда, по его мнению, в компании инфраструктурная команда, да еще и с такими неинтеллигентными личностями.

DevOps — это культура. Культура определяет прежде всего коммуникации между командами. Из этой культуры идет методология (ci/cd/shiping/docking/blue-green/итд). Из методологий идут задачи, реализуемые инструментами.

Исходя из вышеуказанного примера, я вижу как минимум 3 выпавших звена:
1) Коммуникация. Обзывать человека медведем не очень-то красиво.
2) Методология. Вместо отправки PR в репозиторий и оформления задачи — зачем-то надо идти куда-то ногами
3) Задача мониторинга/системы оповещения не была выполнена или использованы не те инструменты. Почему Алексей был не в курсе о том, что у системы есть проблемы? Уверен, зная он про DDOS, то выбрал бы более другое время для своей пользы.

DevOps — это культура.

twitter.com/...​tatus/1168136218418323456 :

Объяснять людям, что девопс — это не профессия, а подход, это как ссать против ветра.

Є два типи людей
Перші топлять за культуру за правильні речі за неймінг конвеншени і так далі
Другі — організовують курси девопс інженерів, будують в компаніях девопс відділи та створюють сервісні девопс-шараги які прийдуть та поставлять вам кубер.

Перші — сердяться на форумах та конференціях.
Другі — мовчки гребуть лопатою кеш, поки є попит.

Так, є люди з інвалідністю, а є інваліди :)

Перші врешті решт завжди програють другим.

Да да! На галере я числюсь как DevOps, а у клиента галеры как Ops (адекватная компания где SAFe и DevOps практики).
Объяснять что-то менеджменту галеры не имеет смысла — умные книжки не читают, проще уволится

1) Коммуникация должна вестись через определенные каналы — а не просто подходить просить — дежурный это публичный интерфейс коммуникации с командой. Я не обзывал человека медведем — это аллегория с помощью которой можно быстрее донести свою мысль
2) Задачи редко кто делает из-за лени, да и зачастую задачи когда создаются то они требуют уточнения, потому как люди часто не понимают конкретной причины
3) Скажите у Вас все девелоперы смотрят на графану? Могу поспорить что многие и в аккаунты свои ни разу не заходили

А зачем тогда нужны инфраструктурные команды? По Вашей логике бухгалтер на галере , который тоже занят сведением баланса или просмотром игр престолов, должен говорить девам «вот вам электронные ключи, там всё просто. делайте всё сами» Может у вас просто рук не хвататет в инфраструктурной команде ?

Плохой пример...
Здравый смысл подсказывает, что передавать свои ключи для отчетности третьим лицам — слегка стремно. Особенно учитывая, что таковые лица не будут нести _никакой_ отвественности за свои ошибки — только владелец ключей))
И да, это действительно на уровне математики за 6 класс... стыдно не разобраться за 20 минут....
Со вторым посылом — согласен на 100%.

Тут дело о том что инфраструктурная команда должна помогать идти вперед всей фирме, а не решать частные вопросы отдельных индивидов. Думаю если бы бухгалтер делала систему оптимизации налогов при которой каждый сотрудник фирмы стал платить скажем на 3% меньше отчислений — то думаю все и каждый бы согласился какое то время позаполнять журналы учета самостоятельно. Не так ли?

Что занчит вопросы отдельных индивидов. Если мы съезжаем с одного стореджа на другой то скорее всего делается это для каких-то нужд бизнеса(возможно банально ради экономии), а не ради чьей-то прихоти. И что такое вся фирма ? У нас большинство айти бизнеса вращается вокруг технологических контор, где продукт как правило и есть главный бизнес, а тут мы опять уперлись в то что это проблемы всей фирмы, т.к. фирма живет с этого продукта.

Класс!
Давно учавствую в бессмысленных дебатах о роли DevOps, ваше объяснение одно из самых доходчивых + прекрасный storytelling

Подписаться на комментарии