Site Reliability Engineer. Хто це такий, за що відповідає та як їм стати?

Site Reliability Engineer – що це за спеціаліст? За що він відповідає, як це пов’язано з підтримкою, DevOps та розробкою? Читайте нижче!

Почнемо, як годиться, з теорії.  Скажу відразу, що ніякої магії тут нема. Родоначальник SRE напряму – компанія Google, зокрема Benjamin Treynor Sloss. Він зібрав команду програмістів для розв’язання проблем з доступністю. Подробиці є в книзі по SRE, яка є безкоштовною та загальнодоступною.

Особисто мене зацікавив напрямок SRE (як назвав цей напрямок Google) ще в момент його зародження. Мене привабило, що можна зламати бар’єр між операційною роботою та розробниками. Мені хотілось бути частиною команди, яка не боїться брати на себе відповідальність за падіння нових сервісів або сервісів після серйозних змін. Головна ідея SRE: якщо система впала – то всі сили повинні бути кинуті на те, як цього більше не допустити, а не з’ясувати, хто винний.

Тепер перейдемо власне до деталей. Що ж такого тут особливого і чому про це говорять?

Хто може стати SRE?

Часто питають, яка різниця між DevOps, Ops, dsevelopers та, власне, SRE? Жодних чарівних знань тут не треба, в SRE може потрапити будь-який інженер, тестувальник, ops чи devops, які хочуть покращувати систему, яким не байдуже, як виглядає система для кінцевого користувача.

Сьогодні до обов’язків SRE включають:

• Alerts – настроювання та обробка сигналів про проблеми в системі.
• Tickets – опис та декларування багів у трекері, коли нема потребі у терміновому втручанні. Наприклад, помилка може почекати кілька днів.
• Logging – наскільки визначення проблеми буде легким та зрозумілим;
• Emergency Response – це час, за яку система буде повністю відновлена ​​з моменту виявлення проблеми.
• Change Management – зробити так, щоб апдейт не руйнував систему.
• Demand Forecasting and Capacity Planning – прогнозування зростання кількості сервісів та запитів для обчислювальних потужностей.
• Provisioning – прорахунок оптимальної потужності для нової системи.
• Efficiency and Performance – перевірка, що система завантажена оптимально і не витрачаються зайві ресурси.

З чого складається діяльність SRE?

По-перше, не менше 50% часу SRE спеціаліста має займати розробка чи написання автоматизації.

Якщо брати загалом, наприклад, протягом місяця, то можна виділити наступні сесії:

• тиждень написання коду у складі команди розробки (взагалі без відволікання на оперативну роботу);
• тиждень як інженер 3 лінії підтримки, плюс аналіз поточного стану системи, написання скриптів автоматизації;
• раз на 2-3 місяці – це тиждень перевірки системи на міцність, коли перевіряється надійність системи переведенням на fail-over систему або на іншу платформу з логуванням часу, roll-back з резервної копії та виконання інших ризикових процедур, які в більшості випадків або не перевіряються взагалі, або перевіряються лише коли “все впало”.

Плюс ще є такі обов’язки:

• Прогнозування кількості ресурсів для нових сервісів.
• Шаблонізація нових сервісів, що спрощує їх моніторинг та введення в промислову експлуатацію.
• Перевірка працездатності резервних копій та резервних серверів.
• Розв’язання проблем без залучення розробників.
• Розрахунок SLA, SLI та SLO – ми точно знаємо що і коли відбуватиметься з нашим сервісом.
• Найголовніше, це руйнування бар’єру між експлуатацією та розробниками.

Як стати SRE? Який кар’єрний шлях треба для цього виконати, який досвід і знання мати?

• Якщо ви молодий спеціаліст, добре піти Junior SRE. Чи записатись на курс Cloud support & DevOps GL BaseCamp, де фахівцями GlobalLogic розроблена спеціальна програма, яка допоможе вам опанувати ази професії. Наприклад, для молодих спеціалістів важливо одразу починати писати софт з автоматизації та моніторингу. Найчастіше, тут потрібні лише навички роботи у Linux і базові навички у створенні;

• У разі зміни кар’єри з програміста потрібно починати працювати з моніторингом і намагатися побачити всю картину в цілому;

На мій погляд, мінімальні знання, якими повинен володіти кожен SRE:

• Знання Linux (зайти і глянути логи, відсортувати, переглянути завантаження процесора).
• Систему моніторингу (nagios, zabbix, prometheus).
• Володіти високорівневою мовою розробки на рівні Middle Developer (nodejs, java, C#, C++, python).
• Знати одну із систем логування (Splunk, ELK). В ідеалі – це реалізація шаблону, який відразу підключить все вищезазначене.

Бонус частина. Міфи про SRE.

• SRE – це моніторинг + on call – це неправда. Ці функції повинні виконуватися службою технічної підтримки або службою моніторингу, ніякий програміст не буде працювати в цілодобовому моніторингу, це спалює будь-який потенціал хорошого розробника.

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

• SRE – чарівна пігулка проти поганого софту. Це теж міф. Щоб покращити доступність сервісу та якості системи потрібно не тільки взяти SRE, DevOps, QA або найняти талановитого програміста, потрібно переглянути підхід компанії в цілому на якість послуг. Якщо немає повноважень на розв’язання проблеми – проблема ніколи не буде вирішена.

Сподіваюсь, ця колонка допомогла вам зрозуміти, хто такий SRE фахівець та з чим він має справу.