Sr net core engineer что это

Где ответственность, или кто такой Senior Software Engineer

Всем привет! Тема специалистов в CIS мне близка: за 10 лет в IT-индустрии я прошел путь от молодого разработчика до руководителя направления и был по обе стороны «баррикад». Потому предлагаю обсудить вопрос исключительно в формате «проблема-решение».

Наш рынок относительно молодой и развивается преимущественно эмпирическим путем: методом проб и ошибок. С одной стороны, это звучит гордо: без толкового профильного образования мы пробились через асфальт. Но в реальности мы теряем огромный потенциал времени. Почему? IT не настолько творческая деятельность, как считают многие, оправдывая свое нежелание брать существующие практики и, тем более, отстаивать их жизнеспособность. Большинство подходов и методов описаны и применялись кем-либо в прошлом или настоящем (пропускаем инновации). Такие проблемы, как отсутствие понимания Delivery Management, использования существующих практик и отсутствие профильных академических знаний заметны не сразу, так как спрос на специалистов по-прежнему превышает их количество на рынке.

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

Думаю, вступительная часть уже вынуждает некоторых начать писать комментарии. Но предлагаю все же дочитать до конца. Я не сторонник жалоб. Это описание реальности, которую, возможно, некоторым не хочется признавать. А теперь давайте разберем причинно-следственную связь и варианты выхода из сложившейся ситуации.

«Seniority»

Сама тема ответственности и распределения обязанностей в производственном цикле разработки проекта широкая, и, видимо, не просто так книжные полки ломятся от профильной литературы. Примечание: проект может быть любого характера, производства ПО можно заменить на производство сарделек. Мы же разберем насущную проблему: «Кто такой Senior Software Engineer?»

Почему в центре нашего внимания именно Senior? Эта фигура является границей между исполнителем и управляющим. Именно этот специалист остается в душе разработчиком, а весь внешний мир требует от него принятия решений и ответственности. Те, кто на все смотрит категорично, сразу займут определенный лагерь. Специалист будет склоняться к тому, что менеджеры просто хотят свалить на него ответственность. Менеджмент же будет склонен считать, что специалист еще не зрел и отложит инициативу в долгий ящик.

Лично я — за баланс и отказ от резких суждений и штампов. Менеджменту нужны люди для роста продукта, проекта или организации (карьеристы не в счет), и у специалиста, чей потенциал был замечен, меняется система метрик его труда. В большинстве случаев осознание Senior-специалистом масштабов и зон ответственности диаметрально меняет его отношение к работе менеджерского состава, учит мыслить целостно, а не частями. Те, кто не справляется, возвращаются обратно и больше не затрагивают тему несправедливости. Но их пример мы опустим. Данный материал нацелен на достижение результата, а не попытку.

1. Результативность

Итак, мы определились с героем рассказа — это Senior специалист. Теперь, войдя в его «шкуру», что мы видим? Ему в той или иной мере присущ нарциссизм. Недостаточное внимание к собственной персоне — мысль, на которой он часто себя ловит (как и все мы, собственно). Мысль эта стимулирует негодование и недовольство текущей средой и ключевыми фигурами. Не нужно ерничать, каждый этого хочет, иначе бы мы не стремились все иметь и рассказать об этом как можно более широкой массе людей про новое авто, гаджет, квартиру и остальное.

Теперь посмотрим на ситуацию глазами взрослого человека. Если у вас есть прибыльное производство, и вы планируете увеличить доходность предприятия, вам нужен заместитель, которые уделит определенному вопросу больше времени, чем вы, и сможет решить его эффективнее, чем вы. Конечно, вы не пожелаете взять на ответственную задачу сомнительного «Senior» специалиста. Не нужно себя обманывать, что кроме вас это никто не сможет сделать лучше. Жизненный цикл растущего предприятия требует смены управленческой модели и структуры для удержания положительной динамики при смене переменных показателей. Это продиктовано здравым смыслом.

То есть, нужно путем анализа выявить потенциально сильного кандидата и разработать для него адаптационную программу по последовательному применению тех навыков, которые он должен будет использовать на новой должности. Если Senior хочет, чтобы его заметили и стали инвестировать в его профессиональный и карьерный рост — он должен сделать первые шаги в этом направлении. Правило № 1: важен только результат, а не попытки.

2. Поиск возможностей

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

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

Простой пример: вы только что закончили мучительно-сложный проект. Со стороны пессимиста вы проклинаете этот прецедент в вашей жизни и с опаской смотрите на каждый последующий. При рассмотрении глазами оптимиста данный прецедент заставляет задуматься над «подводными камнями» (другими словами, извлечь опыт) и выработать модель работы с последующими проектами, не опасаясь, но будучи во всеоружии. Вероятно, этому будут способствовать общения с более опытным специалистом, пройдя тренинг или прочитав профильную литературу. Правило № 2: рассматривать новое как возможность, отдавая отчет окупаемости инвестиций.

3. Самостоятельность

Представим, что наш Senior специалист как минимум не пессимист, но как быть в ситуации, когда ты просто специалист (пешка), а над тобой нависает несколько кругов ада, которые ограничивают тебя в правах и действиях (достаточно распространенное суждение)? На самом деле, ограничения существуют только в голове. Продолжая думать в таком контексте, наш Senior неосознанно начинает искать «уютное» и «стабильное» место, какой-нибудь идеальный проект, в котором все построено по книжкам и царит всеобщее счастье и взаимопонимание.

Давайте договоримся: «уют» и «стабильность» — гибкие и относительные понятия, для постоянного наличия которых нужно много действовать самостоятельно, не ожидая мессии со стороны. Оставаясь в зоне комфорта, человек попадает в ловушку времени и плавно перетекает из состояния динамики в состояние стагнации по принципу лягушки в кипящей воде. Я не встречал ни одну личность, вышедшую из идеальной, рафинированной среды. Любой достойный человек, с которым нам хочется общаться и работать, имеет результаты за спиной и тернистый профессиональный путь.

Возьмем, к примеру, «Senior» специалиста, который не построил процессы, а просто попал в благоприятную среду, и поместим его на новый проект, в котором конь не валялся, а клиент в придачу и не хочет, чтобы он вообще там валялся: 95% специалистов не смогут показать в этой ситуации результат на предыдущем уровне (5% оставляем под потенциально сильных и целеустремленных людей). Проблема в отсутствии должных навыков, которыми казалось бы наш специалист должен обладать.

Senior скажет: «Меня ограничивают!», а теперь побудим спросить его самого себя «Что я уже попытался сделать?». Ответ не поразит своей новизной, список сведется максимум к одной или двум попыткам. Скорее всего, наш специалисты поднимал беспокоящий его вопрос, но:
— он был адресован не тому человеку, который в состоянии его решить или помочь;
— информация не была донесена должным (то есть, ясным) образом;
— предложение поступило в сухой форме, без каких-либо предварительных попыток повлиять на ситуацию или желания самого Senior взять ответственность за результат.

С каждой минутой просветления наш Senior будет перемещать ответственность за результат из зоны внешней среды в поле своего влияния. Правило № 3: хороший проект — проект сделанный своими руками.

4. Hard и Soft навыки

Рассмотренное выше — лишь верхушка айсберга в вопросе личностной мотивации специалиста. Итак, представим, что Senior пребывает в боевом настроении и готов свергнуть горы. Есть проект, в котором наш специалист усмотрел возможности для своего профессионального роста и приступает к выполнению персонального плана развития посредством этого проекта. Он становится автономным, ответственным и ориентированным на результат.

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

Кто всему виной? Конечно, Project Manager, Project Coordinator или Scrum Master. Это их задача — контролировать процесс и обеспечивать эффективное взаимодействие между отделами. «Виноват кто угодно из эшелона менеджмента, только не я — простой и честный трудяга», — думает наш Senior. Давайте рассмотрим роль этих менеджеров. Каждый из вышеперечисленных, может исполнять обязанности без наличия профильных глубинных навыков в технологии. Методологии разработки, такие как RUP, Scrum, Waterfal и другие, служат лишь инструментами, позволяющими абстрагироваться от конечной среды и визуализировать процесс. Исходя из этого, все риски связанные с процессами Risk Management, Change Management, Release Management, Requirements Gathering, Planning, Estimation и остальными требуют вовлеченности и проактивности ключевых специалистов на проекте.

Очередной пример: Senior-специалист, работая над проектом, знает о вероятных последствиях при возникновении конкретных рисков. Он считает свои долгом проинформировать о них и пишет короткое сообщение в общем чате проекта. Долг перед отечеством исполнен — можно спать спокойно. Чем ближе день Икс, тем вероятность возникновения риска выше, и, в конце концов, он «выстреливает». Работа кипит, фаза «ASAP». Ситуацию улаживают, страдает репутация, компания, возможно, терпит издержки в виде штрафов. Никого не интересует, что о проблеме все знали, интересует, почему она не была услышана ключевым составом проекта и не были предприняты действия.

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

Причина в том, что исполнитель, потративший последние лет своей жизни, чтобы занять должность Senior, не смог осознать, что с каждой ролью у него появлялись новые обязанности — большей степени не технического, а организационного характера, в связке с персональными навыками. Правило № 4: Senior на 50% состоит из Hard Skills и на 50% из Soft и Management Skills.

5. Качество, проверенное временем

Заседание продолжается, господа присяжные ©. Senior, посредством продолжительного анализа и работы над собой, постигает состояние равновесия со Вселенной и действительно начинает производить результат, который повышает доходность конечного клиента. Такими результатами можно гордиться и на основании реальных достижений этот специалист становится востребованным, в том числе за стенами родной компании.

Вопрос из зала: «Зачем обучать людей, если они уйдут?» Давайте представим, что мы не инвестируем в людей, и они остаются. Картина получится ужасающая. Senior становится реальной ключевой персоной и логично предположить, что в параллели этой активности будет запущен какой-то Knowledge Management процесс.

Есть цели:
— построить автономный механизм, не зависящий от команды, что в целом является задачей любого профессионала;
— обеспечить возможность продвижения на более высокие позиции;
— минимизировать риски для проекта.

К сожалению, негативные штампы управленческой модели до сих пор живут в сердцах многих людей. Таким кадрам сложно принять, что воспитанные, молодые и амбициозные специалисты могут занять их место. Сказывается незрелость личности. В подобных случаях компания и специалист становятся узниками друг друга, и, с течением времени, эксперт плавно превращается в партизана в динамично меняющейся организации. Правило № 5: результат труда должен простоять не один год.

Тема ответственности за общий результат достигает колоссальных масштабов. Но даже если остановиться сейчас и представить Senior специалиста, который соответствует всем этим пунктам, мы увидим не простого исполнителя, а зрелого и ответственного Senior Software Engineer, который может преодолеть любое испытание в виде поставленных перед ним задач. Такого специалиста хотела бы видеть каждая компания и клиент. Реально ли это? Конечно, реально, и я думаю, что практически каждый знает человека из своего окружения, который вышел за рамки собственных ограничений.

Questrade International Inc.

Вы не можете разместить вакансию или сохранить в черновиках, так как лимиты исчерпаеы.

Запрос пакета

Для просмотра информации зарегестрированных соискателей и использования поисковой системы Staff Search рекомендуем приобрести пакет Расширенный и пакеты больше, либо Staff Search систему, как отдельную услугу, связавшись с нами.

Здесь Вы можете видеть тех пользователей, которые подписаны на страницу Вашей компании. Вы можете искать их по ключевым словам и приглашать для подачи заявки на соответствуюшие активные вакансии. Свяжитесь с нами, если желаете использовать данную возможность.

SRE-инженер. Что нужно знать и уметь?

Рынок труда в ИТ в последние несколько лет активно мутирует, в следствие чего рождаются интересные коллаборации, вроде той, о которой пойдет сегодня речь. Site Reliability Engineering — довольно свежее направление, в котором тесно переплелась разработка и DevOPS. Оно — чисто техническое и довольно сложное даже по меркам ИТ — потребуется очень много знаний (теории) и практики из самых разных направлений разработки и системного администрирования. Сегодня разбираемся что такое SRE и как именно ты будешь зарабатывать много бумажек с изображением американских президентов

SRE на пальцах

SRE ( Site Reliability Engineering ) — набор методов, показателей и предписывающих способов обеспечения надежности систем. Слово «site» в данном контексте читается как «система» или «платформа», а не веб-сайт в привычном нам представлении. SRE — обеспечение надежности всех уровней системы: от физических до логических, это значит, что SRE — это своеобразный конгломерат из разработчика (да, SRE должны уметь в код) и системного администратора со всеми вытекающими.

Именно SRE-инженер стоит в первых рядах, когда речь идёт об обеспечении аптайма highload-сервисов, стабилизации системы после краша и вносят соответствующие поправки в код. Поэтому они часто именуются как Software-инженеры (в совковых конторах это звучало бы как инженер-программист) или инженерами по надежности обслуживания

Вообще, SRE — это своеобразное ответвление, а точнее — своя реализация направления DevOps от Google. Идейным вдохновителем стал Бен Трейнор — текущий вице-президент Google по вопросам облачной обработки данных (где-то упоминается, как вице-президент по технологиям). Так же Google издала уже три книги, где описывает нюансы направления SRE, его практики и применение в недрах компании (Site Reliability Engineering: How Google Runs Production Systems — первая из них)

Зачем нужно это направление?

SRE решает проблемы. А проблемы могут быть, как со стороны разработчиков, так и со стороны инфраструктуры. Программисты пишут код, который работает. Это их работа. Но, зачастую, они не сильно тревожатся по поводу того, насколько он оптимизирован, на какой платформе он будет работать и выдержит ли сервер n-ое количество запросов. Проблемы инфрастуктуры их не касаются.

Специалисты, отвечающие за работоспособность системы, в свою очередь, далеки от мира разработки — они осуществляют трейсинг, сбор логов и ни о каком QA слышать не слышали — без знания кода вообще сложно реагировать на алерты , да и многие инструменты мониторинга требуют интеграции приложения в код. В итоге, вcя эта конъюнктура будет непосредственно влиять на критичные бизнес-процессы, рост расходов на поддержку и инцидент-менеджмент, снижение надежности системы.

— «Парень, который пилит фиксы и лезет в лоад балансер. А убрать, кто ты без него?»

— «Девелопер, сисадмин, интегратор, инженер»

DevOps vs SRE

Эти две сферы не зря сравнивают между собой — они смежные, т.е. часто дублируют функции друг друга. Как мы уже писали выше SRE — это сочетание DevOps и разработки, т.е. умение писать код и погружаться в недры девелопмента тут сочетается с работой по серверной части: администрирование, масштабирование и нагрузку.

Для начала определимся с понятием DevOps — это методология синхронизации и оптимизации рабочих процессов разработки , эксплуатации и техническому обслуживанию ИТ-ландшафта с целью обеспечения качества продукта. Помните шутку про прокладку между рулём и сидением? Эту метаморфозу можно применить и к DevOps-инженеру: работает и с теми, и с другими стараясь максимально оптимизировать пайплайн, который включает в себя проектирование, развертывание релиза (деплонинг), стандартизацию разработки, тестирование, мониторинг (monit, garafana, zabbix) и автоматизацию всех этих процессов вместе взятых

Между двумя направлениями действительно очень тонкая грань. Если сравнивать конкретно работу, то DevOps-инженер — работа больше эксплуатационная, чем созидательная, скажем, 70/30, в случае с SRE этот показатель стремится к 50/50. По-русски: DevOps ближе к системному администрированию, SRE — к разработке . Да, девопс инженеры умеют работать с облаком или писать скрипты для автоматизации работы, но SRE часто намного глубже знакомы с принципами организации работы распределённых систем, их безотказностью, рисками, практических аспектов эксплуатации системы, как в дев, то и в прод среде, при этом, как в случае с DevOps, требуется знание сетей, протоколов, внутренностей ОС.

Скиллы и задачи SRE-инженера

Прокачаться до уровня Senior, т.е. на все 146% будет трудно. Мы уже писали, что профессия не из легких, к тому же сочетает в себе два весьма трудоёмких направления — эксплуатации и разработки.

Девелопмент

Да, SRE-инженер должен уметь писать код на одном из языков программирования, которые используются в стеке компании. Это может быть как C#, так и гугловский Golang, т.е. для позиции SRE нормальной практикой считается не просто написание скриптов (опять же может быть и питон, а может и bash), но и погружение в процессы разработки и постоянное взаимодействие с командой. Опционально может быть: составление брифов (техническое задание), участие в спринтах и копание в бэклоге

Потребуется понимание и опыт работы с концепцией Infrastructure as Code . Так называют модель, которая позволяет управлять инфраструктурой через вызовы соответствующих процедур в коде. Это позволяет избавиться от настройки и тюнинга виртуальных машин в ручном контуре. Среда разработки и инфраструктура при такой модели — единое целое.

Многие проекты переносят свою инфраструктуру в Terraform от Hashicorp . Возможно, вам тоже придётся с этим столкнутся. Terraform — open-source утилита для развертывания и управления вашей облачной инфраструктурой as code, вне зависимости от выбранного провайдера (Google Cloud, Azure, AWS и т.д.). При запуске Terraform читает код и, используя представленные провайдерами облачного сервиса плагины, приводит вашу инфраструктуру к описанному состоянию, совершая необходимые вызовы к API. Легко встраивается в пайплайн проекта и следит за общим состоянием всей инфраструктуры.

Разработка платформы на базе Kubernetes — тоже одна из частых задач в SRE. Kubernetes — это целая экосистема из сервисов и утилит для развёртывания, автоматизации и настройки контейнеризированных приложений и микросервисов (использующие облачные вычисления). Kubernetes дает вам фреймворк для гибкой работы распределенных систем. Он занимается масштабированием и обработкой ошибок в приложении, предоставляет шаблоны развертывания и многое другое. Kubernetes отлично балансирует нагрузку трафика между контейнерами, быстро развернуть или откатить любое количество контейнеров и работает с защищенными протоколами для защиты персональных данных

Так же предстоит работа с билдами в Drone CI. Пул-реквест ты будешь делать чаще, чем оставаться наедине со своей девушкой. Причем не понятно, где интимной близости будет больше. Билд проходит через стандартный конвейер задач и тебе, скорее всего, придётся составлять его пайплайн. Drone — система непрерывной интеграции, основанная на docker-контейнерах, которая отлично работает как с гитхабом, так и с менее известными репозиториями. Каждый шаг из пайплайна обрабатывается в отдельном docker-контейнере и запускаются с помощью drone agent. Drone server, в свою очередь, играет роль координатора

Системное администрирование & автоматизация

Без знания UNIX-систем практически никуда. Windows Server еще встречается, но его концентрация крайне мала. В довесок к знанию архитектуры ОС желательно разбираться в сетевых протоколах (модель OSI, как минимум) и уметь работать с распределением запросов ( балансировка нагрузки ) для повышения отказоустойчивости системы, анализировать технические метрики, придерживаться SLA. Автоматизация работы, связанной с ops (администрированием), написание утилит для уменьшения ручного труда, рутины и оптимизации бизнес-процессов, развёртывание dev-окружения , настройка виртуальных машин — это всё тоже в зоне ответственности SRE-инженера.

По возможным инструментам: для мониторинга метрик, событий из облачной инфраструктуры, контейнеров или оркестраторов используется серверная утилита Telegraf , которая написана на языке Go (тоже опенсорсная)

Траблшутинг & Инцидент менеджмент

Опыт работы в технической поддержке, конечно, пригодится — но тут совсем другой уровень. SRE-инженер обязан разбираться во всех системах мониторинга системы: логи, трейсинг, алертинг. При этом работа не ограничивается на регистрации инцидента — вам необходимо найти причину и найти решение проблемы этого тикета. Саппорт может подразумевать в себе и сменную работу — поэтому, если не имеешь возможность дежурить вечером/ночью, лучше сразу об этом сказать.

С какими инструментами будете работать? В первую очередь — Logstash . Это бесплатное (open source) приложение для парсинга и нормализации логов. Результаты можно выгружать, как в отдельный файл, так и, например, в zabbix или graylog2 для визуализации определенных метрик.

Kibana — специальный дашборд для построения графиков и диаграмм этих самых логов. Как правило, используется в стеке, т.н. ELK — Elasticsearch + Logstash + Kibana

Работа с базами данных & облачной инфраструктурой

Основа основ в SRE. Все мало-мальски топовые компании переводят свою инфраструктуру в облако — это не дань моде, а вполне закономерный тренд. Поэтому приготовьтесь к миграции базы данных из MySQL в Azure или AWS, настройке бэкапов, оптимизации запросов, написанию тулз, выставление лимитов, обкатывание баз на стенде, тестированию и развертывание всего этого дела в продуктивной среде.

Плюсом будет умение работы с Microsoft Azure на уровне разработчика : разбираться в Azure Data Explorer (служба для анализа большого объема потоковых данных в реальном из приложений и/или сервис в real-time), работать и автоматизировать систему управления идентификацией и доступом (AIM), использовать Azure REST API (доступ к ресурсам службы через протокол HTTP), управлять инфраструктурой через Azure CLI (интерфейс командной строки).

Что еще? Формирование политик RBAC. Role Based Access Control — управление доступом на основе ролей, альтернатива спискам ACL. Суть подхода заключается в создании ролей, повторяющих бизнес-роли в компании, и присваивание их пользователям. На основе этих ролей проверяется возможность выполнения пользователем того или иного действия.

Софт-скиллы

Без них в сегодняшней ИТ-компании никуда. Даже сугубо техническим специалистам придётся научиться работать в команде, уметь договариваться, балансировать не только нагрузку на сервер, но и свою стрессоустойчивость, прививать себе лидерские качества прокачивать тайм-менеджмент, следовать традициям blameless culture.

Что за Blameless Сulture?

Всё чаще многие хрюши многозначительно кивают в сторону blameless culture. «Безупречная культура», которая, как говорят, первой появилась на производственных линиях Тойоты, теперь становится мейнстримом в ИТ-компаниях. Основные её постулаты гласят:

Путь разработчика в SRE: зачем идти в инфраструктуру и что из этого выйдет

Около года назад я переквалифицировался из .NET-разработчика в SRE. В этой статье делюсь историей о том, как группа опытных разработчиков отложила в сторону C# и пошла изучать Linux, Terraform, Packer, рисовать NALSD и строить IaC, как мы применяли практики экстремального программирования для управления инфраструктурой компании, и что из этого вышло.

В Додо Пицце больше 600 пиццерий в 13 странах мира, а большая часть процессов в пиццериях управляется с помощью информационной системы Dodo IS, которую мы сами пишем и поддерживаем. Поэтому надёжность и стабильность системы важны для выживания.

Сейчас стабильность и надёжность информационной системы в компании поддерживает команда SRE (Site Reliability Engineering), но так было не всегда.

Предыстория: параллельные миры разработчиков и инфраструктуры

Много лет я развивался как типичный fullstack-разработчик (и немного scrum-мастер), учился писать хороший код, применял практики из Extreme Programming и старательно уменьшал количество WTF в проектах, к которым прикасался. Но чем больше появлялось опыта в разработке ПО, тем больше я осознавал важность надёжных систем мониторинга и трейсинга приложений, качественных логов, тотального автоматического тестирования и механизмов, обеспечивающих высокую надёжность сервисов. И всё чаще стал заглядывать «через забор» к команде инфраструктуры.

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

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

Бермудский треугольник проблем

Однако я начну издалека — с проблем, ради которых все эти пляски нужны.

Проблемы разработчиков

Два года назад мы поняли, что большая сеть пиццерий не может жить без собственного мобильного приложения и решили его написать:

• собрали классную команду;
• за полгода написали удобное и красивое приложение;
• подкрепили торжественный запуск «вкусными» промоакциями;
• и в первый же день благополучно упали под нагрузкой.

Косяков на старте было, конечно, много, но больше всего мне запомнился один. На время разработки на продакшене был развёрнут один слабый сервер, почти калькулятор, который обрабатывал запросы с приложения. Перед публичным анонсом приложения его нужно было увеличить — мы живем в Azure, и это решалось нажатием одной кнопки.

Но эту кнопку никто не нажал: команда инфраструктуры даже не знала, что сегодня релизится какое-то приложение. Они решили, что следить за продакшеном «некритичного» сервиса — обязанность команды приложения. А разработчик бэкенда (это был его первый проект в Додо) решил, что в крупных компаниях этим занимаются ребята из инфраструктуры.

Тем разработчиком был я. Тогда я вывел для себя очевидное, но важное правило:

Сейчас это не сложно. В последние годы появилось огромное количество инструментов, которые позволяют программистам заглянуть в мир эксплуатации и ничего не сломать: Prometheus, Zipkin, Jaeger, ELK стек, Kusto.

Тем не менее у многих разработчиков до сих пор есть серьёзные проблемы с теми, кого называют инфраструктурой/DevOps’ами/SRE. В итоге программисты:

Зависят от команды инфраструктуры. Это вызывает боль, недопонимание, иногда взаимную ненависть.

Проектируют свои системы в отрыве от реальности и не учитывают, где и как будет выполняться их код. Например, архитектура и дизайн системы, которая разрабатывается для жизни в облаке, будет отличаться от дизайна системы, которая хостится on-premise.

Не понимают природу багов и проблем, связанных с их кодом. Особенно это заметно, когда проблемы связаны с нагрузкой, балансировкой запросов, сетью или производительностью жёстких дисков. Разработчики не всегда располагают этими знаниями.

Не могут оптимизировать деньги и другие ресурсы компании, которые используются для поддержания их кода. По нашему опыту бывает так, что команда инфраструктуры просто заливает проблему деньгами, например, увеличивая размер сервера БД на продакшене. Поэтому часто проблемы кода даже не доходят до программистов. Просто почему-то инфраструктура начинает стоить дороже.

Проблемы инфраструктуры

Сложности есть и «на другой стороне».

Сложно управлять десятками сервисов и окружений без качественного кода. У нас в GitHub сейчас больше 450 репозиториев. Часть из них не требует операционной поддержки, часть мертва и сохраняется для истории, но значительная часть содержит сервисы, которые нужно поддерживать. Им нужно где-то хоститься, нужен мониторинг, сбор логов, единообразные CI/CD-пайплайны.

Чтобы всем этим управлять, мы ещё недавно активно использовали Ansible. В нашем Ansible-репозитории было:

• 60 ролей;
• 102 плейбука;
• обвязка на Python и Bash;
• тесты в Vagrant, запускаемые вручную.

Причина крылась в том, что этот код не использовал многие стандартные практики в мире разработки ПО. В нём не было CI/CD-пайплайна, а тесты были сложными и медленными, поэтому всем было лень или «некогда» запускать их вручную, а уж тем более писать новые. Такой код обречён, если над ним работает более одного человека.

Без знания кода сложно эффективно реагировать на инциденты. Когда в 3 часа ночи в PagerDuty приходит алерт, приходится искать программиста, который объяснит что и как. Например, что вот эти ошибки 500 аффектят пользователя, а другие связаны со вторичным сервисом, конечные клиенты его не видят и можно оставить всё так до утра. Но в три часа ночи программистов разбудить сложно, поэтому желательно самому понимать, как работает код, который ты поддерживаешь.

Многие инструменты требуют встраивания в код приложения. Ребята из инфраструктуры знают, что нужно мониторить, как логировать и на какие вещи обращать внимание для трейсинга. Но встроить это всё в код приложения часто не могут. А те, кто могут, не знают что и как встраивать.

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

Проблемы бизнеса

У бизнеса тоже есть две большие проблемы, которые нужно решать.

Прямые потери от нестабильности системы, связанной с надёжностью и доступностью.
В 2018 году у нас произошёл 51 критический инцидент, а критичные элементы системы не работали в сумме больше 20 часов. В деньгах это 25 млн. рублей прямых потерь из-за несозданных и недоставленных заказов. А сколько мы потеряли на доверии сотрудников, клиентов и франчайзи, — подсчитать невозможно, в деньгах это не оценивается.

Расходы на поддержку текущей инфраструктуры. При этом компания поставила перед нами цель на 2018 год: в 3 раза уменьшить стоимость инфраструктуры в пересчёте на одну пиццерию. Но ни программисты, ни DevOps-инженеры в рамках своих команд не могли даже приблизиться к решению этой задачи. Этому есть причины:

• с одной стороны, для решения таких задач нужны программисты с глубокими знаниями инфраструктуры;
• с другой стороны, нужны operations (назовём их баззвордом DevOps), которые умеют программировать на хорошем промышленном уровне;
• с третьей стороны, бизнесу нужен баланс между надёжностью и доступностью этих систем и их стоимостью.

И что с этим делать?

Как решить все эти проблемы? Решение мы нашли в книге «Site Reliability Engineering» от Google. Когда прочли, поняли — это то, что нам нужно.

Но есть нюанс — чтобы всё это внедрить нужны годы, и с чего-то надо начинать. Рассмотрим исходные данные, которые у нас были изначально.

Вся наша инфраструктура почти полностью живет в Microsoft Azure. Есть несколько независимых кластеров для прода, которые разнесены по разным континентам: Европа, Америка и Китай. Есть нагрузочные стенды, которые повторяют продакшн, но живут в изолированной среде, а также десятки DEV-окружений для команд разработчиков.

Из хороших практик SRE у нас уже были:

• механизмы мониторинга приложений и инфраструктуры (спойлер: это мы в 2018 думали, что они хорошие, а сейчас уже всё переписали);
• процессы для дежурств 24/7 on-call;
• практика ведения постмортемов по инцидентам и их анализ;
• нагрузочное тестирование;
• CI/CD-пайплайны для прикладного софта;
• хорошие программисты, которые пишут хороший код;
• евангелист SRE в команде инфраструктуры.

Команда инфраструктуры перегружена. На глобальные улучшения не хватало времени и сил из-за текущей операционки. Например, мы очень долго хотели, но не могли избавиться от Elasticsearch в своём стеке, или продублировать инфраструктуру у другого облачного провайдера, чтобы избежать рисков (тут могут посмеяться те, кто уже пробовал в мультиклауд).

Хаос в коде. Инфраструктурный код был хаотичен, разбросан по разным репозиториям и нигде не задокументирован. Всё держалось на знаниях отдельных людей и больше ни на чём. Это была гигантская проблема управления знаниями.

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

Онбординг SRE-команды

Чтобы решить эти проблемы и как-то начать двигаться в сторону SRE, мы запустили проект онбординга. Только это был не классический онбординг — обучение новых сотрудников (новичков), чтобы добавить людей в текущую команду. Это было создание новой команды из инженеров инфраструктуры и программистов — первый шаг к полноценной структуре SRE.

На проект мы выделили 4 месяца и поставили три цели:

1. Обучить программистов тем знаниям и навыкам, которые необходимы для дежурств и операционной деятельности в команде инфраструктуры. — описание всей инфраструктуры в коде. Причём это должен быть полноценный программный продукт с CI/CD, тестами.
2. Пересоздать всю нашу инфраструктуру из этого кода и забыть про ручное накликивание виртуалок мышкой в Azure.

Две составляющие онбординга: обучение и практика

Онбординг состоял из двух частей: обучения и работы над инфраструктурой в коде.

Обучение. На обучение выделялось минимум 3 часа в день:

• на чтение статей и книг из списка литературы: Linux, сети, SRE;
• на лекции по конкретным инструментам и технологиям;
• на клубы по технологиям, например, по Linux, где мы разбирали сложные случаи и кейсы.

После демо мы заводили обсуждения под каждой темой в Slack, где заинтересованные участники могли асинхронно обсуждать всё детальнее. Так мы избегали длинных встреч на 10 человек, но при этом все в команде хорошо понимали, что происходит с нашей инфраструктурой и куда мы катимся.

Практика. Вторая часть онбординга — создание/описание инфраструктуры в коде. Эту часть разделили на несколько этапов.

Реверс–инжиниринг инфраструктуры. Это первый этап, на котором разобрали, что где задеплоено, как что работает, где какие сервисы работают, где какие машины и их размеры. Всё полностью задокументировали.

Концепты. Мы экспериментировали с разными технологиями, языками, подходами, выясняли, как можем описать нашу инфраструктуру, какие инструменты стоит для этого использовать.

Написание кода. Сюда входило само написание кода, создание CI/CD-пайплайнов, тестов и построение процессов вокруг всего этого. Мы написали код, который описывал и умел создавать с нуля нашу дев-инфраструктуру.

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

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

• Terraform для описания текущей инфраструктуры.
• Packer и Ansible для создания образов виртуальных машин.
• Jsonnet и Python как основные языки разработки.
• Облако Azure, потому что у нас там хостинг.
• VS Code — IDE, для которой создали единые настройки, расширенный набор плагинов, линтеров и прочего, чтобы писать унифицированный код и расшарили их между всеми разработчиками.
• Практики разработки — одна из основных вещей, ради которой затевался весь этот карнавал.

Практики Extreme Programming в инфраструктуре

Главное, что мы, как программисты, принесли с собой — это практики Extreme Programming, которые используем в работе. XP — гибкая методология разработки ПО, соединяющая в себе выжимку из лучших подходов, практик и ценностей разработки.

Нет ни одного программиста, который бы не использовал хотя бы несколько из практик Extreme Programming, даже если он об этом не знает. При этом в мире инфраструктуры данные практики обходят стороной, несмотря на то, что они в очень большой степени пересекаются с практиками из Google SRE.

О том, как мы адаптировали XP для инфраструктуры, есть отдельная статья. Но если вкратце: практики XP работают и для кода инфраструктуры, пусть с ограничениями, адаптациями, но работают. Если хотите их применять у себя, зовите людей с опытом применения этих практик. Большинство из этих практик так или иначе описаны в той самой книге о SRE.

Всё могло бы сложиться хорошо, но так не бывает.

Технические и антропогенные проблемы на пути

В рамках проекта было два вида проблем:

• Технические: ограничения «железного» мира, недостаток знаний и сырые инструменты, которыми приходилось пользоваться, потому что других нет. Это привычные любому программисту проблемы.
• Человеческие: взаимодействие людей в команде. Общение, принятие решений, обучение. С этим было хуже, поэтому нужно остановиться подробнее.

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

• Опытные программисты с годами опыта, за которые они выработали свои подходы, привычки и ценности в работе.
• Другая группа из мира инфраструктуры со своим опытом. У них другие шишки, другие привычки, и они тоже считают, что знают как правильно жить.

Но избежать этого столкновения невозможно. Если позовёте в проект сильных программистов и слабых инженеров инфраструктуры, то у вас будет однонаправленный обмен знаний. Наоборот тоже не работает — одни проглотят других и всё. А вам нужно получить некую смесь, поэтому нужно быть готовым к тому, что «притирка» может оказаться очень долгой (в нашем случае мы смогли стабилизировать команду лишь спустя год, попрощавшись при этом с одним из самых сильных в техническом плане инженеров).

Если хотите собрать именно такую команду, не забудьте позвать сильного Agile- коуча, scrum-мастера, или психотерапевта — что больше нравится. Возможно, они помогут.

Итоги онбординга

По итогам проекта онбординга (он завершился в октябре 2019 года) мы:

• Создали полноценный программный продукт, который управляет нашей DEV-инфраструктурой, с собственным CI-пайплайном, с тестами и прочими атрибутами качественного программного продукта.
• Удвоили количество людей, которые готовы дежурить и сняли нагрузку с текущей команды. Спустя ещё полгода эти люди стали полноценными SRE. Теперь они могут потушить пожар на проде, проконсультировать команду программистов по НФТ, или написать свою библиотеку для разработчиков.
• Сместили майндсет в сторону идей SRE. Не только у участников проекта онбординга, но и у тех программистов из продуктовых команд, которые теперь могут разговаривать с нами на одном языке.
• Сильно устали: и те, кто участвовал в онбординге, и те, кто участвовал в дежурствах.

Вместо выводов: инсайты, не наступайте на наши грабли

Несколько инсайтов от разработчика. Не наступайте на наши грабли, сэкономьте себе и окружающим нервы и время.

Инфраструктура пока в прошлом. Когда я учился на первом курсе (15 лет назад) и начинал изучать JavaScript, у меня из инструментов были NotePad ++ и Firebug для отладки. C этими инструментами уже тогда нужно было делать какие-то сложные и красивые вещи.

Примерно так же я ощущаю себя сейчас, когда работаю с инфраструктурой. Текущие инструменты только формируются, многие из них ещё не вышли в релиз и имеют версию 0.12 (привет, Terraform), а у многих регулярно ломается обратная совместимость с предыдущими версиями.

Для меня, как энтерпрайз-разработчика, использовать на проде такие вещи – абсурд. Но других просто нет.

Читайте документацию. Как программист, я относительно редко обращался к докам. Я достаточно глубоко знал свои инструменты: любимый язык программирования, любимый фреймворк и БД. Все дополнительные инструменты, например, библиотеки, обычно написаны на том же языке, а значит всегда можно посмотреть в исходники. IDE всегда подскажет, какие и где нужны параметры. Даже если я ошибусь, то быстро это пойму, запустив быстрые тесты.

В инфраструктуре так не получится, там огромное количество различных технологий, которые необходимо знать. Но глубоко всё знать невозможно, а многое написано на неведомых языках. Поэтому внимательно читайте (и пишите) документацию — без этой привычки здесь долго не живут.

Комментарии в коде инфраструктуры неизбежны. В мире разработки комментарии — признак плохого кода. Они быстро устаревают и начинают врать. Это признак того, что разработчик не смог иначе выразить свои мысли. При работе с инфраструктурой комментарии так же признак плохого кода, но без них уже не обойтись. Для разрозненных инструментов, которые слабо связаны друг с другом и ничего не знают друг о друге, без комментариев не обойтись.

Часто под кодом скрываются обычные конфиги и DSL. При этом вся логика происходит где-то глубже, куда нет доступа. Это сильно меняет подход к коду, тестированию и работе с ним.

Не бойтесь пускать разработчиков в инфраструктуру. Они могут привнести полезные (и свежие) практики и подходы из мира разработки ПО. Пользуйтесь практиками и подходами от Google, описанными в книге про SRE, получайте пользу и будьте счастливы.

PS: Я специально не стал затрагивать в этой статье темы микросервисов, Кубернетеса и прочие хайповые вещи, с которыми приходится учиться жить, так как это большая тема для отдельной статьи.

PPS: Эта статья написана по моему выступлению на DevOpsConf осенью 2019 года. С тех пор прошло довольно много времени, и теперь уже точно понятно, что всё было не зря: тойл теперь не съедает бОльшую часть времени инженеров, наша команда теперь может реализовывать крупные долгосрочные проекты по улучшению инфраструктуры в широком смысле, а программисты почти не жалуются на безумных DevOps-инженеров, которые только мешают жить.

PPPS: В этом году конференция, посвящённая DevOps-практикам, будет называться DevOps Live 2020. Изменения коснутся не только названия: в программе будет меньше докладов и больше интерактивных обсуждений, мастер-классов и воркшопов. Рецепты о том, как расти и перестраивать процессы с помощью DevOps-практик. Формат также изменится — два блока по два дня и «домашние задания» между ними.

Чтобы узнать подробнее о том, что будет происходить на DevOps Live и что полезного вынесут инженеры, безопасники, тимлиды и CTO, подписывайтесь на рассылку и следите за публикациями в блоге.