SRE-інженер: хто такий і як ним стати?

Активний інтерес до цієї позиції з’явився у 2016 році, коли Google розповіла, кого в компанії називають Site Reliability Engineer. За їхніми словами, на цій позиції фахівці постійно стикаються із питаннями навколишніх про те, чим вони займаються.

Суть у тому, що у розробці більшу частину часу всі фокусуються на створенні програмних систем. Про те, що відбувається після створення програми — говорять мало. Хоча саме на цей період припадає 40-90% зусиль та витрат. Звідси з’являється потреба в дисципліні, яка розглядає весь життєвий цикл програмних об’єктів: від створення до розгортання та експлуатації, доопрацювання та до мирного виведення з експлуатації. Цю дисципліну компанія назвала проєктуванням надійності сайту.

SRE гарантує, що послуги та продукти компанії надійні, мають достатній для користувача час безвідмовної роботи та швидкі темпи вдосконалення. 

Напрямки роботи SRE

1. Проєктування, створення та обслуговування інфраструктури 

SRE-інженер тісно працює з командами розробників та допомагає з плануванням ресурсів для продуктів: і нових, і наявних. Він бере участь у визначенні навантаження та вимог до відтермінувань. Участь у цих етапах допоможе SRE-інженеру приймати правильні рішення щодо інфраструктури.

Також SRE може оптимізувати витрати на інфраструктуру. Рідше такий спеціаліст відповідає ще й за відповідність інфраструктури вимогам, таким як GDPR та SOC2. 

Найчастіше передбачається робота не з приватною хмарою, а з публічною: AWS або Google Cloud. Для управління та опису інфраструктури зараз багато хто обирає підхід IaC — інфраструктура як код. Наприклад, у Pinterest, Oracle та Reddit. 

2. Підтримка надійності виробничих систем

Для reliability важливо розуміти, як досягти правильної роботи сервісу та дотримуватися внутрішніх стандартів. Тут знадобляться SLO, SLI та бюджети на помилки.

* SLO — це мета рівня обслуговування, тобто ті обіцянки, які ви даєте клієнту за конкретними показниками. У таких угодах прописані очікування клієнтів, що дає чітке розуміння командам розробників та DevOps, чого вони мають досягти та на які критерії орієнтуватися.

* SLI — індикатор рівня обслуговування. Він вказує на відповідність фактичних показників вимогам SLO. Індикатори повинні бути простими, щоб їх було легко відстежувати, і лише найважливіші, щоб команді не довелося контролювати зайві показники. 

Коли відомо SLO, їх можна взяти за основу для бюджетів на помилки. Він означає допустимий період, коли показники сервісу можуть бути нижчими за вказані в SLO. Жодна система не застрахована від збоїв на 100%, тому цей запас у вигляді бюджету на помилки і є необхідним. Бюджет дозволяє зрозуміти серйозність інциденту. Якщо на нього пішло, наприклад, 30% бюджету, він вважається серйозним.

3. Моніторинг та алерти

Визначивши SLO, ви повинні слідкувати за тим, щоб вони дотримувалися. Це робиться за допомогою моніторингу та SLI. 

Моніторинг може охоплювати піки використання процесора та пам’яті, аптайм сервісу, його продуктивність. Для цього можна взяти такі інструменти, як Prometheus та Grafana, або популярні SaaS, такі як Datadog та Sentry.

Перше завдання — налаштувати моніторинг та алерти. Важливо поставити правильні пороги, щоб не вийшло так, що на команду сиплються алерти, що не існують. У такому разі можна пропустити щось важливе, що спричинить збій. Погодьтеся, краще заздалегідь дізнаватися про передумови інцидентів і діяти на випередження, ніж отримати повідомлення, коли все лягло.

4. Чергування, реагування на інциденти, постмортеми 

Коли моніторинг та алерти налаштовані, потрібно створити графік чергувань. Потім розділити у команді обов’язки щодо реагування на них. Для цього краще використовувати платформи для керування інцидентами. Так інциденти та алерти будуть в одному місці.

Ще одне важливе завдання — написання постмортем. Це невеликі статті, які зазвичай пишуть після великих помилок чи збоїв. У них описується, що сталося, що до цього призвело і що зроблено, щоб такого не повторилося. Постмортеми допомагають пояснити внутрішнім та зовнішнім замовникам суть інцидентів та як їх уникнути у майбутньому.

5. Нові інструменти та автоматизація 

Один із принципів SRE — менше ручного втручання. Google вважає, що всі рутинні та завдання, що повторюються, потрібно автоматизувати. Вони забирають час та відривають від інших важливих проєктів. Тому SRE-інженер робить автоматичне реагування на часті алерти, налаштовує процес CI/CD або створює програми, які допоможуть розробникам виконувати рутинні запити.

Як справи з SRE в Україні

В Україні ця область поки що не дуже насичена пропозиціями. Але SRE потрібні в таких компаніях як Intellias, Infopulse та Raiffeisen Bank. 

Щоб стати SRE-інженером, потрібен досвід:

• В адмініструванні та налаштуванні Linux. Це основа, без неї ніяк.
• Глибоке знання та досвід із публічними хмарними платформами. Найчастіше йдеться про Microsoft Azure або AWS.
• З технологіями надання інфраструктури — Terraform. 
• Контейнерними технологіями та оркеструванням — Docker, Kubernetes.
• Використання інструментів IaC та інструментів керування конфігурацією, наприклад, Ansible та Puppet.
• У моніторингу, наприклад, Prometheus.

Далі є кілька варіантів: 

1. Якщо ви, читаючи ці пункти, в голові промовляли: “Ага, це є, і це є …”, то можете стати SRE-інженером вже зараз. 
2. Якщо вам цікаво розвиватися в цьому напрямку, але поки в чомусь не дотягуєте — ми допоможемо наблизитися до першого варіанту. У нас ви можете підібрати курси системного адміністратора на будь-яку тему вище.