Рынок труда в ИТ в последние несколько лет активно мутирует, в следствие чего рождаются интересные коллаборации, вроде той, о которой пойдет сегодня речь. 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. «Безупречная культура», которая, как говорят, первой появилась на производственных линиях Тойоты, теперь становится мейнстримом в ИТ-компаниях. Основные её постулаты гласят:
- Любая ошибка — это возможность проанализировать проблемы и изъяны, а не искать виноватого
- Человек не должен замалчивать о проблеме под страхом увольнения
- Необходимо создать условия, в которых можно и нужно не замалчивать о проблемах, а подробно о них рассказывать.
- Компании выгодно выявлять свои систематические уязвимости, не сваливая при этом вину на человеческий фактор
Как вам статья?
