Sre команда что это
После DevOps: как стать SRE и устроиться на работу в Google
SRE — это Site Reliability Engineer
В IT отрасли это инженер, который отвечает за надежность очень сложных сервисов. Появилась профессия в Google и придумали методологию именно там. Оно и понятно, Гугл – это сервис, который использует весь мир. Это огромные мощности и большая сложность.
14 декабря в работе гугла был сбой, весь мир был в недоумении. Вот в таких случаях и нужен SRE-инженер. Он не должен допустить подобных промахов.
Методологию DevOps российский IT-рынок освоил раньше и теперь ведутся жаркие споры об SRE vs DevOps. Кто-то говорит, что это одно и тоже, кто-то, что SRE это нечто, что логично продолжает DevOps. В России профессия только появилась. Крупные банки, которые содержат большие мощности, стали серьезно задумываться о таких ребятах.
В общем, Пока все спорят, мы решили пообщаться об SRE и DevOps, а также о работе в Гугл и Тинькофф.
Одного SRE я нашла в Tinkoff, до этого он работал в Google – у первоисточника, так сказать. Зовут его Дима Масленников. Google мы уделили отдельное внимание, так как есть стереотип, что работать там весело. Мы выяснили, что не всем.
В статье приведен краткий и творчески переработанный текст интервью. Если хочется подробностей или лень читать, смотрите полную версию на моем youtube-канале
Фаря:
– Как ты попал в Google?
Дмитрий Масленников:
– Они меня очень долго хантили. Писали мне в LinkedIn, просили мое резюме, а я всё забывал им его прислать…
– Почему их футболил? Это же, блин, Google!
– Не знаю, мне в России было хорошо.
– А чем ты занимался в этот момент?
– Был программистом, архитектором ПО. Занимался разработкой бэкенда.
А почему именно на тебя обратили внимание, как ты думаешь?
– Понятия не имею. У меня были всякие громкие слова вписаны в профиле, потому что я работал на всякие Еbay, Samsung. И видимо, обилие этих громких имен и технологий, с которыми я работал, и сыграли роль.
– Они тебя SRE обучали? Ведь в России такого не было и нет до сих пор.
– Да, и нигде в мире такого нет. Поэтому обучение проходит в Google примерно полгода.
– Вокруг SRE идут дикие дискуссии. Что это, является ли SRE противопоставлением DevOps, является ли оно его дополнением?
– Я когда работал в eBay, я хорошо прочувствовал, что было до DevOps. Есть разработка (программисты) и есть администраторы. И они друг друга никогда не видят. Ты передал код руководителю, и он где-то лежит. Он, в свою очередь, тоже кому-то там передал. И кто-то этот код как-то эксплуатирует. DevOps же сказал, что их надо посадить вместе.
– В какой момент здесь появляется SRE?
– SRE появляется, когда софт становится чрезмерно сложным и чрезмерно нагруженным. Во-первых, сам функционал растет очень сильно. И это, порой, незаметно. Ну что поменялось в Google-поиске за последний год или за последние 5 лет? А там релизы идут каждую неделю с новым функционалом! Причем, именно с функционалом.
Когда появились гики, которые собирали машины у себя в гаражах, они были невероятно популярны и все хотели быть такими же умными как они. Но мир поменялся. Сейчас это навык, который могут иметь все и оценивается он не сильно высоко. Также будет и с программистами.
– Я вообще даже не представляю, что там можно обновлять?
– Например, ты кофе ищешь. Во-первых, геолокация. Если ты кофе ищешь в поле, то наверно ты ищешь, как его выращивают или историю. Если кофе ищешь в центре мегаполиса, то, наверное, попить. Или Хилтон. Это фамилия или отель?
– Так, а SRE тут где?
– Во-первых, растет функционал, растет сложность, растет нагрузка. То есть, мы охватываем всё больше и больше людей, интернет становится доступнее и доступнее. Например, присоединяется Индия и другие, ранее недоступные страны и местности. Всё становится географически очень широким. И соответственно люди начинают потреблять, у сервиса растет нагрузка. И это дает чрезмерную сложность.
Одно дело открыть сервис только на Москву, другое – на всю Россию. Нагрузка колоссальная. И что происходит? Чтобы обслужить такое количество людей быстро, нужно очень много серверов. Сервисы должны быть доступны 24×7. Представь, если сейчас у тебя платеж будет идти не 5 минут, а три дня?
И вопрос, что администратору с этим всем делать?
– Я предположу, что есть много администраторов. И они существуют в сложной иерархии, чтобы всё это дело поддерживать.
– Администраторами, как пишет Google, расти невыгодно. Нанимать столько людей уже невозможно. Вот поэтому и появилось SRE.
– В какой момент DevOps становится SRE?
– Очень философский вопрос. Есть задачи и есть проблемы. Их нужно решать. Например, если в банке не выполнились переводы, то что делать? Решать проблему. Называть ли это SRE или не называть – непонятно.
Ну, и это вообще просто такой спор ни о чём. «Есть ли жизнь на Марсе, нет ли жизни на Марсе?» Является ли SRE DevOps’ом, не является ли SRE DevOps’ом? И SRE, и DevOps – это про то, как делать хорошо. Значит, берём лучшее отовсюду, применяем, чтобы пользователи были довольны.
– То есть две методологии работают в связке?
– В связке, но SRE всё-таки не администраторы, у них больше упор на программирование и автоматизацию. Плюс, я постоянно топлю за то, что мы административными методами редко должны работать. А если это происходит, то значит у нас что-то не так.
– Но это не ответ на вопрос.
– Они могут быть братья, они могут перекликаться, может быть одно и тоже – как хотите. А действия-то как поменяются? Всё равно всё сводится к одному: есть софт, его надо эксплуатировать, нужны какие-то люди, которые будут решать проблемы по нагрузке. И как их назвать – дело десятое.
– SRE может стать DevOps или программист? Вообще, что нужно изучать, чтобы стать востребованным SRE?
— Мне кажется, что надо учить не программирование, не SRE и DevOps, а думать про процесс, как про инженерное дело, которое присутствует в разработке программного обеспечения и оно многофакторное.
Недавно мы митап проводили про SRE, мы много спорили, но в одном мы сошлись: программисты уже не нужны так, как раньше. Нужны всем инженеры, которые могут решать проблемы. Когда появились гики, которые собирали машины у себя в гаражах, они были невероятно популярны и все хотели быть такими же умными как они. Но мир поменялся. Сейчас это навык, который могут иметь все и оценивается он не сильно высоко. Также будет и с программистами.
Про работу SRE в Google
– Давай про Гугл. Есть легенды про плюшки в Гугл при трудоустройстве. Расскажи поподробнее.
– Во-первых, когда уходишь с прошлого места работы, они спрашивают: «Сколько премий ты потеряешь, увольняясь?». Они компенсируют эти деньги, чтобы ты не раздумывал. Потом мне сняли на 3 месяца квартиру, дали отдельного риелтора от Google, который подбирает жилье. Либо они могут компенсировать тебе все расходы по переезду.
Первую неделю работы они тебе рассказывают вообще не про работу, а про то, как жизнь в Гугле и Ирландии устроена. В компании всё очень спокойно. Там везде микрокухни – фруктики, и прочее. Общение в микрокухнях – отдельная культура. Ещё есть трехразовое питание, массажи и раз в неделю можно прийти на работу с питомцем.
И такая мантра есть от менеджера – «главное, не перегори, не переработай.»
Ещё у нас история интересная была. Парень устроился сразу после вуза, и решил сэкономить на жилье. Он купил самый дешёвый фургон, поставил туда кровать. В Google есть прачечные, аккумуляторы он заряжал в офисе, душ и полотенца тоже имеются. Фургон поставил на парковку у офиса и ходил с нее на работу.
Он хотел быстро выплатить кредит за обучение. Но потом ему так делать запретили.
– Почему?
– В СМИ пошла новость, стали обсуждать, а Google не нравится большая активность. Репутация брэнда, все дела…
– А почему ты уехал в Россию и трудоустроился в Тинькофф? Это так нетипично. Все стараются свалить, а ты вернулся.
– Не знаю, бренд интересный и я клиент очень давно. Где ещё работать в России? Ну, Яндекс, ну Тинькофф. А уехал, потому что в Дублине скучно стало.
– Почему в Дублине скучно?
– Это маленький город. Это не Шенген, чтобы поехать в Европу – надо получать визу.
По-нашему менталитету Дублин – это деревня. Когда местные говорят, что они устали от Дублина, потому что там вайб большого города, для жителей Москвы это звучит смешно.
Но плюсы там были, например, очень спокойные люди. Там вообще никто не повышает голос. В России то, что не считается повышением голоса, после Дублина выглядит контрастно.
– А почему в Google скучно? Что у Тинькофф есть такого, что нет у Google?
– В Тинькофф есть драйв и хорошая агрессивность.
«Мы хотим там расти, мы хотим захватывать рынки, мы хотим быть лучшими.»
А в Google: «Мы уже лучшие. Мы уже всё захватили. Ну, что-то мы ещё хотим дозахватить в Китае, но там политические проблемы».
Если вам понравилось, ищите подробности в полной версии интервью.
Еще раз о DevOps и SRE
По мотивам дискуссии в чате AWS Minsk Community
В последнее время разгораются настоящие битвы на предмет определения понятия DevOps и SRE.
Несмотря на то, что уже во многом дискуссии на эту тему уже набили оскомину, в том числе и мне, решил вынести на суд хабра-сообщества и свой взгляд на эту тему. Тем, кому интересно, добро пожаловать под кат. И да начнется все по новой!
Предыстория
Итак, в стародавние времена жила отдельно команда разработчиков ПО и администраторов серверов. Первые благополучно писали код, вторые, употребляя различные теплые ласковые слова в адрес первых, настраивали сервера, периодически приходя к разработчикам и получая в ответ исчерпывающее «на моей машине все работает». Бизнес ждал программное обеспечение, все простаивало, периодически ломалось, все нервничали. Особенно тот, кто за весь этот бардак платил. Славная ламповая эпоха. Ну да вы и так в курсе, откуда растут ноги у DevOps.
Рождение DevOps практик
Затем пришли серьезные дяди и сказали — это не индустрия, так работать нельзя. И притащили модели жизненного цикла. Вот, например, V-модель.
Итак, что мы видим? Бизнес приходит с концепцией, архитекторы проектируют решения, разработчики пишут код, дальше — провал. Кто-то как-то тестирует продукт, кто-то как-то его доставляет конечному пользователю и где-то на выходе этой чудо-модели сидит одинокий бизнес-заказчик и ждет обещанной у моря погоды. Пришли к выводу — нужны методы, которые позволят этот процесс наладить. И решили создать практики, которые бы их реализовывали.
И решили они назвать их DevOps практиками — думаю имели в виду from Development to Operations. Придумали разные мудреные штуки — CI/CD практики, практики, основывающиеся на IaC принципе, тысячи их. И понеслась, разработчики пишут код, DevOps инженеры трансформируют описание системы в виде кода в работающие системы (да, код это к сожалению, всего лишь описание, но никак не воплощение системы), доставка крутится, ну и так далее. Вчерашние администраторы, освоив новые практики, гордо переквалифицировались в DevOps инженеров, и все понеслось. И был вечер, и было утро… извините, не оттуда.
Все опять не слава богу
Только все улеглось, и разные хитрые «методологи» начали писать толстенные книги по DevOps практикам, тихо разгорались споры, кто же такой все-таки пресловутый DevOps инженер и что DevOps — это культура производства, опять назрело недовольство. Внезапно обнаружилось, что доставка ПО — абсолютно нетривиальная задача. У каждой инфраструктуры разработки свой стек, где-то собирать надо, где-то разворачивать environment, тут нужен tomcat, тут нужен еще хитровымученный способ запуска — в общем, голова трещит. А еще проблема, как ни странно, оказалась в первую очередь в организации процессов — вот эта функция доставки, как бутылочное горлышко, стало блокировать процессы. К тому же эксплуатацию (Operations) никто не отменял. Ее в V-модели не видно, а там еще весь жизненный цикл справа. По итогу надо и как-то инфраструктуру поддерживать, и в мониторинг смотреть, и инциденты разруливать, да еще и доставкой заниматься. Т.е. сидеть одной ногой и в разработке, и в эксплуатации — и вдруг получился такой Development & Operations. А тут еще и повальный хайп на микросервисы подъехал. А с ними еще и разработка с локальных машин начала в клауд переезжать — попробуй что-то отладить локально, если микросервисов десятки и сотни, тут уже постоянная доставка становится средством выживания. Для «маленькой скромной компании» еще куда ни шло, но все же? А Google?
SRE от Google
Пришел Google, съел самые крупные кактусы и решил — нам такое не надо, нам надежность нужна. А надежностью надо управлять. И решил — нам нужны специалисты, которые будут управлять надежностью. Назвал их SR-инженерами и сказал, вот вам все, сделайте, как обычно, хорошо. Вот вам SLI, вот вам SLO, вот вам мониторинг. И ткнул носом в operations. И назвал свой «надежный DevOps» SRE. Вроде бы все хорошо, но есть один грязный хак, который Google мог себе позволить — на позиции SR инженеров нанимать людей, которые имели квалификацию разработчиков и еще немного шили на дому разбирались в функционировании работающих систем. Причем с наймом таких людей и у самого Google проблемы — главным образом потому, что тут он сам с собой конкурирует — надо же и бизнес-логику кому-то описывать. Доставку развесил на релиз-инженеров, SR — инженеры управляют надежностью (ясное дело, не напрямую, а влияя на инфраструктуру, меняя архитектуру, отслеживая изменения и показатели, разбираясь с инцидентами). Красиво, можно книги писать. А что делать, если вы не Google, а надежность все же как-то беспокоит?
Развитие идей DevOps
Тут как раз подоспел Docker, выросший из lxc, а затем и различные системы оркестрации типа Docker Swarm и Kubernetes, и DevOps инженеры выдохнули — унификация практик упростила доставку. Упростила до такой степени, что стало возможным даже отдать доставку разработчикам — что там deployment.yaml. Контейнеризация проблему решает. Да и зрелость систем CI/CD уже на уровне один файл написал и все понеслось — разработчики сами справятся. И тут мы начинаем говорить, как нам сделать свой SRE, с… да хоть с кем-нибудь.
SRE не в Google
Ну ок, доставку мы отдали, вроде бы можем выдохнуть, вернуться к старым добрым временам, когда админы смотрели загрузку процессоров, тюнили системы и тихо потягивали из кружек что-то непонятное в тишине и спокойствии… Стоп. Мы не ради этого все затевали (а жаль!). Внезапно оказывается, что в подходе Google мы вполне можем взять отличные практики — не загрузка процессоров важна, и не то, насколько часто мы диски там меняем, или там в клауде стоимость оптимизируем, а бизнес-метрики — все те же пресловутые SLx. И управление инфраструктурой с них никто не снимал, и инциденты разруливать надо, и дежурить на посту периодически, и вообще в теме бизнес-процессов быть. И парни, начинайте уже понемногу программировать на хорошем уровне, вас Google уже заждался.
Резюмируя. Внезапно, но вы уже устали читать и вам не терпится плюнуть написать автору в комментарии к статье. DevOps как практики доставки, был есть и будет. И никуда не денется. SRE как набор практик эксплуатации делает эту самую доставку успешной.
Обязанности SRE-инженера в зарубежных вакансиях
Введение
В 2016 году Google выпустила ту самую книгу о SRE (Site Reliability Engineering). Эта практика решала важную задачу компании — поддержание высокой надёжности сервисов Google. За годы практика широко распространилась среди разработчиков по всему миру. Теперь во многих стартапах и крупных корпорациях есть должность SRE-инженера.
Так менялся интерес работодателей к SRE-инженерам с течением времени.
Тренд поиска SRE-инженеров
Практика относительно новая, так что пока не совсем понятно, что конкретно должны делать SRE-инженеры. Можно, конечно, почитать книжки или посмотреть видео, но полный список должностных обязанностей по ним не составишь.
Результаты аналитики
Мы выделили несколько основных обязанностей:
Деплой и обслуживание инфраструктуры (84% объявлений).
Определение и контроль SLO, SLI и бюджетов на ошибки (34% объявлений).
Настройка мониторинга и алертов (47% объявлений).
Дежурство, реагирование на инциденты, постмортемы (47% объявлений).
Создание инструментов и автоматизация (56% объявлений).
Комментарий Евгения Бутырина, технического редактора Слёрм
В вакансиях Российских компаний эти обязанности также присутствуют, в тех или иных формулировках. С упоминанием обязанностей в процентом соотношении всё не так прозрачно. Зачастую в вакансиях пишут где-нибудь в требованиях: уметь в мониторинг. А в обязанностях ни слова, но мы понимаем, что раз нужно знать, значит понадобится. Та же история с SLO и бюджетом на ошибки, будучи одними из основных практик, по умолчанию подразумевается, что это надо знать и уметь. А про дежурства может быть написано: обеспечивать работоспособность сервисов 24/7.
Деплой и обслуживание инфраструктуры
Одна из главных задач SRE-инженера — проектировать, создавать и обслуживать инфраструктуру, в которой работают продукты и сервисы компании. Это может быть частное облако, но все чаще публичное, например AWS или Google Cloud. Сейчас популярно писать инфраструктуру как код (IaC), используя синтаксис YAML и HCL (для продуктов Hashicorp, вроде Terraform).
Чтобы принимать правильные решения об инфраструктуре, SRE-инженер должен участвовать в планировании ресурсов для новых и существующих продуктов, в том числе обсуждать с командами по продуктам и другими инженерами примерную нагрузку, требования к задержкам и т. д.
Иногда SRE-инженер отвечает за комплаенс инфраструктуры, особенно за соблюдение GDPR и SOC2. Наконец, большинство компаний стараются оптимизировать расходы на инфраструктуру, и этим тоже должен заниматься SRE.
Определение и контроль SLO, SLI и бюджетов на ошибки
Поддерживать надёжность производственных систем — важная обязанность SRE-инженера. Все-таки R в SRE означает reliability. Нужно понимать, как достичь корректной работы сервиса и соблюсти внутренние стандарты.
Для этого SRE-инженер определяет SLO и SLI. SLO — это показатели целевого уровня обслуживания для сервиса, а SLI — индикаторы, которые измеряют эти уровни. SLO можно определить вместе с коллегами на основе ожиданий клиентов и обязательств перед клиентами, сформулированных в виде SLA.
Когда SLO определены, их можно использовать как основу бюджетов на ошибки, то есть допустимого периода, когда сервис может работать ниже целевых уровней. В любой системе сбои неизбежны, и командам SRE и разработчиков нужен этот запас в виде бюджета на ошибки. С помощью бюджета можно измерять серьёзность инцидентов. Если, например, инцидент истратил 30% бюджета, его можно считать серьёзным.
Комментарий Павла Селиванова, Архитектора VK Cloud Solutions, спикера Слёрм
Ещё с помощью бюджета можно понимать когда нужно работать над новыми фичами, а когда стоит поработать над стабильностью продукта.
Настройка мониторинга и алертов
Когда SLO определены, можно следить за их соблюдением с помощью SLI и мониторинга. Обычно мониторинг охватывает инфраструктуру (пики использования процессора и памяти), аптайм сервиса (веб-сайта или API), производительность (скорость загрузки страницы) и т. д. Можно использовать локальные инструменты, вроде Prometheus и Grafana, или популярные SaaS, например Datadog и Sentry.
Настройка мониторинга и алертов — это первый шаг. Нужно установить адекватные пороги, чтобы на команду не хлынул поток несущественных алертов. Алерты должны быть связаны с конкретными действиями, причем лучше заранее узнавать о симптомах, чтобы принимать меры, а не получать уведомления об уже случившихся сбоях.
Дежурство, реагирование на инциденты, постмортемы
Мы настроили мониторинг и получаем алерты, а теперь надо составить график дежурств и распределить обязанности по реагированию среди членов команды. Лучше использовать платформу управления инцидентами, чтобы все инциденты и алерты были собраны в одном месте, причём у каждого инцидента должен быть чётко определён ответственный сотрудник. Это поможет рассчитать важные метрики, вроде MTTA (среднее время реагирования) и MTTR (среднее время восстановления).
Ещё одна задача SRE-инженера — писать постмортемы, чтобы объяснить внешним и внутренним стейкхолдерам, какая цепочка событий привела к инциденту, какие меры были приняты и что было сделано, чтобы такого не повторилось.
Комментарий Павла Селиванова, Архитектора VK Cloud Solutions, спикера Слёрм
Создание инструментов и автоматизация
Один из принципов SRE — устранение ручного труда. Google SRE определяет тяжелый труд как выполняемые вручную, повторяющиеся и нетактические задачи, которые можно автоматизировать. Эти задачи отнимают время разработчиков и SRE и мешают другим важным проектам. Автоматизировать повторяющиеся задачи — одна из важных обязанностей SRE-инженера. Это может быть автоматическое реагирование на распространённые алерты, настройка процесса CI/CD, чтобы команда работала быстрее, или создание продуктов, с помощью которых разработчики могут сами выполнять рутинные запросы.
Другие обязанности
В некоторых компаниях SRE-инженеры могут выполнять и другие задачи:
Отладка проблем в продакшене. Может затрагивать все уровни стека.
Разработка мультиоблачной стратегии. Сейчас всё больше рабочих нагрузок мигрирует в публичное облако, но стоит избегать зависимости от вендора — так дешевле и надёжнее. Поэтому сейчас многие компании стараются приспособить свои продукты к разным облачным платформам.
Хаос-инжиниринг. Впервые применен Netflix, а сейчас внедряется и в других компаниях. Это метод, при котором мы стараемся сломать систему изощрёнными способами, чтобы проверить ее устойчивость.
Заключение
Как видите, SRE-инженер должен не просто обслуживать инфраструктуру или помогать с CI/CD. Поддержание нормальной работы сервисов затрагивает разные области эксплуатации и разработки программного обеспечения.
Евгений Бутырин
Над материалом работала команда курса «SRE: внедряем DevOps от Google». Учебный центр Слёрм работу не обещает, но спикеры могут кое-чему научить.
Путь разработчика в SRE: зачем идти в инфраструктуру и что из этого выйдет
В Додо Пицце больше 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-репозитории было:
Причина крылась в том, что этот код не использовал многие стандартные практики в мире разработки ПО. В нём не было CI/CD-пайплайна, а тесты были сложными и медленными, поэтому всем было лень или «некогда» запускать их вручную, а уж тем более писать новые. Такой код обречён, если над ним работает более одного человека.
Без знания кода сложно эффективно реагировать на инциденты. Когда в 3 часа ночи в PagerDuty приходит алерт, приходится искать программиста, который объяснит что и как. Например, что вот эти ошибки 500 аффектят пользователя, а другие связаны со вторичным сервисом, конечные клиенты его не видят и можно оставить всё так до утра. Но в три часа ночи программистов разбудить сложно, поэтому желательно самому понимать, как работает код, который ты поддерживаешь.
Многие инструменты требуют встраивания в код приложения. Ребята из инфраструктуры знают, что нужно мониторить, как логировать и на какие вещи обращать внимание для трейсинга. Но встроить это всё в код приложения часто не могут. А те, кто могут, не знают что и как встраивать.
«Сломанный телефон». В сотый раз объяснять, что и как мониторить, неприятно. Проще написать общую библиотеку, чтобы передать её программистам для переиспользования в своих приложениях. Но для этого нужно уметь писать код на том же языке, в том же стиле и с теми же подходами, которые используют разработчики ваших приложений.
Проблемы бизнеса
У бизнеса тоже есть две большие проблемы, которые нужно решать.
Прямые потери от нестабильности системы, связанной с надёжностью и доступностью.
В 2018 году у нас произошёл 51 критический инцидент, а критичные элементы системы не работали в сумме больше 20 часов. В деньгах это 25 млн. рублей прямых потерь из-за несозданных и недоставленных заказов. А сколько мы потеряли на доверии сотрудников, клиентов и франчайзи, — подсчитать невозможно, в деньгах это не оценивается.
Расходы на поддержку текущей инфраструктуры. При этом компания поставила перед нами цель на 2018 год: в 3 раза уменьшить стоимость инфраструктуры в пересчёте на одну пиццерию. Но ни программисты, ни DevOps-инженеры в рамках своих команд не могли даже приблизиться к решению этой задачи. Этому есть причины:
И что с этим делать?
Как решить все эти проблемы? Решение мы нашли в книге «Site Reliability Engineering» от Google. Когда прочли, поняли — это то, что нам нужно.
Но есть нюанс — чтобы всё это внедрить нужны годы, и с чего-то надо начинать. Рассмотрим исходные данные, которые у нас были изначально.
Вся наша инфраструктура почти полностью живет в Microsoft Azure. Есть несколько независимых кластеров для прода, которые разнесены по разным континентам: Европа, Америка и Китай. Есть нагрузочные стенды, которые повторяют продакшн, но живут в изолированной среде, а также десятки DEV-окружений для команд разработчиков.
Из хороших практик SRE у нас уже были:
Команда инфраструктуры перегружена. На глобальные улучшения не хватало времени и сил из-за текущей операционки. Например, мы очень долго хотели, но не могли избавиться от Elasticsearch в своём стеке, или продублировать инфраструктуру у другого облачного провайдера, чтобы избежать рисков (тут могут посмеяться те, кто уже пробовал в мультиклауд).
Хаос в коде. Инфраструктурный код был хаотичен, разбросан по разным репозиториям и нигде не задокументирован. Всё держалось на знаниях отдельных людей и больше ни на чём. Это была гигантская проблема управления знаниями.
«Есть программисты, а есть инженеры инфраструктуры». Несмотря на то, что у нас достаточно хорошо была развита культура DevOps, всё ещё было это разделение. Два класса людей с абсолютно разным опытом, которые говорят на разных языках и пользуются разными инструментами. Они, конечно, дружат и общаются, но часто не понимают друг друга из-за совершенно разного опыта.
Онбординг SRE-команды
Чтобы решить эти проблемы и как-то начать двигаться в сторону SRE, мы запустили проект онбординга. Только это был не классический онбординг — обучение новых сотрудников (новичков), чтобы добавить людей в текущую команду. Это было создание новой команды из инженеров инфраструктуры и программистов — первый шаг к полноценной структуре SRE.
На проект мы выделили 4 месяца и поставили три цели:
Две составляющие онбординга: обучение и практика
Онбординг состоял из двух частей: обучения и работы над инфраструктурой в коде.
Обучение. На обучение выделялось минимум 3 часа в день:
После демо мы заводили обсуждения под каждой темой в Slack, где заинтересованные участники могли асинхронно обсуждать всё детальнее. Так мы избегали длинных встреч на 10 человек, но при этом все в команде хорошо понимали, что происходит с нашей инфраструктурой и куда мы катимся.
Практика. Вторая часть онбординга — создание/описание инфраструктуры в коде. Эту часть разделили на несколько этапов.
Реверс–инжиниринг инфраструктуры. Это первый этап, на котором разобрали, что где задеплоено, как что работает, где какие сервисы работают, где какие машины и их размеры. Всё полностью задокументировали.
Концепты. Мы экспериментировали с разными технологиями, языками, подходами, выясняли, как можем описать нашу инфраструктуру, какие инструменты стоит для этого использовать.
Написание кода. Сюда входило само написание кода, создание CI/CD-пайплайнов, тестов и построение процессов вокруг всего этого. Мы написали код, который описывал и умел создавать с нуля нашу дев-инфраструктуру.
Пересоздание стендов для нагрузочного тестирования и продакшена. Это четвёртый этап, который должен был идти после онбординга, но его пока отложили, так как профита от него, как ни странно, гораздо меньше, чем от дев-окружений, которые создаются/пересоздаются очень часто.
Вместо этого мы переключились на проектную деятельность: разбились на небольшие подкоманды и занялись теми глобальными инфраструктурными проектами, до которых раньше не доходили руки. Ну и конечно включились в дежурства.
Практики Extreme Programming в инфраструктуре
Главное, что мы, как программисты, принесли с собой — это практики Extreme Programming, которые используем в работе. XP — гибкая методология разработки ПО, соединяющая в себе выжимку из лучших подходов, практик и ценностей разработки.
Нет ни одного программиста, который бы не использовал хотя бы несколько из практик Extreme Programming, даже если он об этом не знает. При этом в мире инфраструктуры данные практики обходят стороной, несмотря на то, что они в очень большой степени пересекаются с практиками из Google SRE.
О том, как мы адаптировали XP для инфраструктуры, есть отдельная статья. Но если вкратце: практики XP работают и для кода инфраструктуры, пусть с ограничениями, адаптациями, но работают. Если хотите их применять у себя, зовите людей с опытом применения этих практик. Большинство из этих практик так или иначе описаны в той самой книге о SRE.
Всё могло бы сложиться хорошо, но так не бывает.
Технические и антропогенные проблемы на пути
В рамках проекта было два вида проблем:
Прошло два месяца, но фаза шторминга продолжалась. Только ближе к концу проекта мы осознали, что все проблемы, с которыми мы боролись и не воспринимали, как связанные друг с другом были следствием общей корневой проблемы — в команде сошлись две группы абсолютно разных людей:
Но избежать этого столкновения невозможно. Если позовёте в проект сильных программистов и слабых инженеров инфраструктуры, то у вас будет однонаправленный обмен знаний. Наоборот тоже не работает — одни проглотят других и всё. А вам нужно получить некую смесь, поэтому нужно быть готовым к тому, что «притирка» может оказаться очень долгой (в нашем случае мы смогли стабилизировать команду лишь спустя год, попрощавшись при этом с одним из самых сильных в техническом плане инженеров).
Если хотите собрать именно такую команду, не забудьте позвать сильного Agile- коуча, scrum-мастера, или психотерапевта — что больше нравится. Возможно, они помогут.
Итоги онбординга
По итогам проекта онбординга (он завершился в октябре 2019 года) мы:
Вместо выводов: инсайты, не наступайте на наши грабли
Несколько инсайтов от разработчика. Не наступайте на наши грабли, сэкономьте себе и окружающим нервы и время.
Инфраструктура пока в прошлом. Когда я учился на первом курсе (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, подписывайтесь на рассылку и следите за публикациями в блоге.