что такое sre инженер
Еще раз о 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 как набор практик эксплуатации делает эту самую доставку успешной.
Think SRE: смотрим на проекты глазами SRE-инженера
В отзывах о Слёрме Kubernetes звучала фраза: «Kubernetes оказался проще, чем я думал». Сейчас уже не звучит, мифа о сложности k8s больше нет. Он перешел в разряд инструментов easy to learn, hard to master.
Мы хотим повторить то же самое с SRE. Показать, что SRE проще и понятнее, чем кажется. Сдвинуть парадигму: дать людям посмотреть на проект глазами инженера SRE.
Как всегда на старте, в уравнении много неизвестных. И как всегда на старте, самое интересное достанется первым.
3-5 февраля мы проводим в Москве Слёрм SRE. Билет на трехдневный интенсив стоит 60 тысяч. Что же участник получит за свои деньги?
Когда я рассказываю друзьям и коллегам про SRE, я встречаю здоровый скептицизм:
Эти вопросы я хочу разобрать.
Пора узнать, что такое SRE
На уровне лозунгов: SRE — это одна из имплементаций DevOps. Она появилась 10+ лет назад в Google, но только недавно стала проникать на «обычный» рынок, в первую очередь благодаря книге Site Reliability Engeneering, выпущенной Google в 2016 году.
О связи SRE и DevOps хорошо рассказано в этом видео:
Плохо то, что лозунги — ни о чём. Ну DevOps, ну имплементация, очередное «за всё хорошее против всего плохого».
Можно прочитать книгу (и стоит это сделать). Но читатель окажется в положении человека, изучающего каратэ по рисункам. Книга описывает концепцию без приложения к реальности. Преподаватель ведет за руку по конкретному пути и в процессе указывает на ошибки.
В цену входит быстрый и глубокий обзор подхода и инструментов SRE.
Внедрить SRE проще, чем кажется
На Слёрме мы будем щупать SRE руками: выберем метрики, настроим их измерение, алерты, столкнемся с инцидентами, решим и разберем их, перестроим проект по всем канонам SRE.
То есть дадим пошаговую инструкцию, которую можно внедрить у себя по возвращении с интенсива.
Вру. По сути мы дадим не инструкцию, а образец, с которого можно срисовать кучу идей и решений.
В цену входит образец для внедрения.
Главная проблема в том, что вам предстоит убеждать тех, кто не был на Слёрме. Поэтому в идеале стоит прийти на интенсив всей командой. Поэтому мы даем большие скидки для групп.
Хорошо бы на Слёрм прийти во главе с СТО. И СЕО тоже полезно, и об этом раздел…
… как убедить топ-менеджмент, что SRE полезен и нужен.
Обычно между СЕО (топ-менеджментом), СТО (IT-менеджментом), разработчиками и эксплуатацией есть конфликт задач.
Я намеренно не говорю «конфликт интересов», это именно конфликт задач.
СЕО нужны финансовые показатели. СТО — понятная, управляемая и по возможности комфортная ситуация. То есть понятные таски с понятным бизнес-велью, соблюдение сроков, нормальный стек, больше фич и меньше факапов. Разработчикам нужно выкатывать больше фич, а эксплуатации — обеспечить доступность (что явно конфликтует с «больше фич»).
SRE говорит, что у всех участников процесса есть единая задача: счастье пользователя. Пользователя делает счастливым здоровый баланс между новыми фичами и надежностью сервиса. Счастливый пользователь платит больше денег. Для управления счастьем пользователя нужен специализированный инструментарий.
Более того, SRE, будучи основан на метриках, позволяет переводить финансовые показатели в целевые показатели различных метрик, а их в свою очередь — в задачи DevOps-команд.
Позволяет переводить — это я преувеличил. Наличие этих метрик позволяет найти взаимосвязи между состоянием метрик и финансовыми показателями. Это отдельная большая, но понятная задача.
Есть проект DORA, DevOps Research & Assessments, он выпускает ежегодные исследования по ценности для бизнеса и ROI DevOps и его подкласса SRE. Мы сейчас переводим актуальный отчет на русский язык. Там есть оценочные формулы, которые с известной степенью точности можно применить к вашей компании.
Резюме: SRE дает бизнесу возможность управлять финансовыми показателями, устанавливая целевые показатели метрик, а DevOps-команда, глядя на текущие значения метрик, однозначно понимает, чем сейчас нужно заниматься с максимальной пользой для финансовых показателей. Какой СЕО откажется от такого инструмента?
Получить ресурсы на внедрение SRE вполне реально.
В цену курса входит набор доводов в пользу перехода на SRE и DevOps.
И даже в маленьких компаниях есть место SRE.
SRE делится на инструменты, культуру и организационную структуру.
Часть инструментов, например, Service Mesh, нужны для больших и сложных проектов. Но те же retry, backoff, failure injection, graceful degradation можно внедрять и в малых проектах, и дают они громадную отдачу.
Культура тоже полезна в любой компании. Классический администратор, настраивая Prometheus, будет действовать по стандарту: включит мониторинг потребления памяти и диска, и другие привычные мониторинги. SRE-инженер сперва пойдет обсуждать с бизнесом ключевые показатели бизнес-процессов, а затем настроит их мониторинг. Сразу видно, что культура SRE-инжиниринга полезна даже в микро-стартапе.
А вот организационная структура в маленьких компаниях, наверно, не нужна и даже вредна. Когда все сотрудники — универсалы, не надо принудительно выделять SRE-команды.
Все, что мы описываем, уже работает
Эдуард проводит вебинар «SRE — хайп или будущее?» 12 декабря в 11:00.
О программе
Что касается программы. Я уже получаю фидбек экспертов, что программа «не бьётся»: она слишком широкая и местами нелогичная. Это действительно так.
По сути у нас есть каркас программы, набор идей, которые мы хотим раскрыть. У нас впереди два месяца напряженной работы, по мере подготовки программа будет уточняться: уберем лишнее, уточним оставшееся.
Но уже в текущем виде программа ясно показывает направление, в котором мы работаем.
Тема №1: Основные принципы и методы SRE
Тема №2: Дизайн распределенных систем
Тема №3: Как принимают проект SRE
Тема №4: Проектирование и запуск распределенной системы
Тема №5: Monitoring, Observability and Alerting
Тема №6: Практика тестирования надежности систем
Тема №7: Практика incident response
Тема №8: Практика управления нагрузкой
Тема №9: Реагирование на инциденты
Тема №10: Диагностика и решение проблем
Тема №11: Тестирование надежности систем
Тема №12: Самостоятельная работа и ревью
Стоит ли все вышеперечисленное своих денег?
PS. При чем тут хаб Kubernetes
Вся практика выполняется в Kubernetes. Тем, кто владеет Kubernetes, прямая дорога в SRE-инженеры. Тем, кто не владеет — на наши курсы по Kubernetes.
Кто такой SRE-инженер?
Задача современного SRE-инженера — сделать так, чтобы система была надежной, стабильной и производительной. Да, это похоже на задачи классического системного администратора, однако в случае с SRE цель достигается немного иными способами. SRE-инженер, как и сисадмин, должен понимать устройство инфраструктуры, быть в курсе, какое ПО работает, знать, какую нагрузку выдерживают серверы, понимать, как надо работать с утилитами операционной системы.
На практике выделяют 4 ключевых направления, которые отличают SRE-инженера от классического системного администратора.
1. SRE-инженер — это, в первую очередь, программист
Да, это программист, но с навыками администрирования. При этом в отличие от большинства разработчиков ПО он пишет код не в целях реализации бизнес-логики, а в целях повышения стабильности и производительности системы. То есть написание кода не является основной задачей SRE-инженера — это всего лишь способ достижения основной цели.
Таким образом, умение программировать помогает SRE-специалисту самостоятельно находить ошибку в программе и исправлять ее. Он без проблем залезет в код, найдет причину и сразу устранит проблему.
Кроме того, SRE-инженер может разрабатывать утилиты, помогающие следить за системой. К примеру, у вас на проекте уже есть утилиты трассировки либо сбора логов, однако они чем-то не устраивают SRE-инженера, но для него это не проблема, ведь он может либо написать свои утилиты, либо доработать существующие.
2. SRE-инженер применяет модель «Инфраструктура как код» (IaC)
Такой специалист старается не менять ничего в системе вручную, то есть он пишет для всего скрипты и конфигурационные файлы. Зачем? Да хотя бы для того, чтобы снизить вероятность человеческой ошибки. Кроме того, данный подход даёт возможность легко воспроизводить настройки на прочих серверах и узнавать, как именно система настроена.
3. SRE-инженер принимает участие в проектировании архитектуры
SRE-инженер в курсе, какие серверы применяют в компании, какова их мощность, как они настроены, существуют ли технические ограничения. С такими знаниями он способен предвидеть потенциальную проблему, следовательно, может заранее сообщить о ней программистам.
А еще он может уже на старте разработки определить критерии для программистов, которым надо следовать. К примеру, для приложения следует обеспечить возможность записи логов в конкретное место или же надо интегрироваться с общей мониторинговой системой. И если данные требования не выполнены, SRE-инженер не примет приложение на поддержку.
4. SRE-инженер активно использует метрики
Оценка стабильности системы происходит не по ощущениям, а по фактическим параметрам. Существуют 2 главные метрики: 1. SLO — цели уровня обслуживания. Речь идет о соглашении о метриках и допустимых значениях, причем пороговые значения превышаться не должны. К примеру, наибольший даунтайм системы — не более 20 часов/год, среднее время ответа сервиса — не более 1 секунды. 2. SLI — индикаторы уровня обслуживания. Это уже сами метрики, измеряющие в течение какого-либо времени. К примеру, даунтайм системы в год — 18 часов, среднее время ответа сервиса — 0,8 секунды.
Как раз таки на основании этих метрик и происходит оценка стабильности и производительности приложений. А если что-либо выходит за рамки установленных параметров, SRE-инженер имеет право наложить вето на разработку нового функционала и попросить разработчиков сконцентрироваться на устранении проблем.
Практический пример
Допускается, чтобы сервис завершал работу с ошибкой 5 раз в месяц. Еще не так давно в месяц было 2-3 ошибки. Однако за последние 2 недели случились уже 3 ошибки, следовательно, если такая тенденция сохранится, лимит на 5 месячных ошибок будет превышен. Учитывая ситуацию, SRE-специалист может сказать разработчикам: «Ошибок стало больше. Пока стабильность не вернется на прежний уровень, мы не можем пускать в production ни одной новой функции».
SRE-инженер. Что нужно знать и уметь?
Экспириенс, задачи, нагрузка
Ingredients
Directions
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-ое количество запросов. Проблемы инфрастуктуры их не касаются.
— «Парень, который пилит фиксы и лезет в лоад балансер. А убрать, кто ты без него?»
— «Девелопер, сисадмин, интегратор, инженер»
DevOps vs SRE
Эти две сферы не зря сравнивают между собой — они смежные, т.е. часто дублируют функции друг друга. Как мы уже писали выше SRE — это сочетание DevOps и разработки, т.е. умение писать код и погружаться в недры девелопмента тут сочетается с работой по серверной части: администрирование, масштабирование и нагрузку.
Скиллы и задачи SRE-инженера
Прокачаться до уровня Senior, т.е. на все 146% будет трудно. Мы уже писали, что профессия не из легких, к тому же сочетает в себе два весьма трудоёмких направления — эксплуатации и разработки.
Девелопмент
Да, SRE-инженер должен уметь писать код на одном из языков программирования, которые используются в стеке компании. Это может быть как C#, так и гугловский Golang, т.е. для позиции SRE нормальной практикой считается не просто написание скриптов (опять же может быть и питон, а может и bash), но и погружение в процессы разработки и постоянное взаимодействие с командой. Опционально может быть: составление брифов (техническое задание), участие в спринтах и копание в бэклоге
Разработка платформы на базе Kubernetes — тоже одна из частых задач в SRE. Kubernetes — это целая экосистема из сервисов и утилит для развёртывания, автоматизации и настройки контейнеризированных приложений и микросервисов (использующие облачные вычисления). Kubernetes дает вам фреймворк для гибкой работы распределенных систем. Он занимается масштабированием и обработкой ошибок в приложении, предоставляет шаблоны развертывания и многое другое. Kubernetes отлично балансирует нагрузку трафика между контейнерами, быстро развернуть или откатить любое количество контейнеров и работает с защищенными протоколами для защиты персональных данных
Так же предстоит работа с билдами в Drone CI. Пул-реквест ты будешь делать чаще, чем оставаться наедине со своей девушкой. Причем не понятно, где интимной близости будет больше. Билд проходит через стандартный конвейер задач и тебе, скорее всего, придётся составлять его пайплайн. Drone — система непрерывной интеграции, основанная на docker-контейнерах, которая отлично работает как с гитхабом, так и с менее известными репозиториями. Каждый шаг из пайплайна обрабатывается в отдельном docker-контейнере и запускаются с помощью drone agent. Drone server, в свою очередь, играет роль координатора
Системное администрирование & автоматизация
Траблшутинг & Инцидент менеджмент
Опыт работы в технической поддержке, конечно, пригодится — но тут совсем другой уровень. SRE-инженер обязан разбираться во всех системах мониторинга системы: логи, трейсинг, алертинг. При этом работа не ограничивается на регистрации инцидента — вам необходимо найти причину и найти решение проблемы этого тикета. Саппорт может подразумевать в себе и сменную работу — поэтому, если не имеешь возможность дежурить вечером/ночью, лучше сразу об этом сказать.
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. «Безупречная культура», которая, как говорят, первой появилась на производственных линиях Тойоты, теперь становится мейнстримом в ИТ-компаниях. Основные её постулаты гласят: