Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Тестування у SRE: чи є куди розвиватись

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт DOU! У теперішні часи невизначеності я хотів би поділитися з вами деякими думками щодо SRE і розказати про кар’єрні можливості для інженерів-тестувальників в цій актуальні дисципліні.

Що таке SRE

Почнемо з того, що оригінальна інтерпретація абревіатури SRE або «Site Reliability Engineering» сьогодні дещо розширилась. Літера «S» наразі може мати значення як «site», так і тлумачення «system», «service», «software» і навіть означати «online Stuff» у найширшому розумінні цього слова. Під літерою «R» зазвичай розуміють надійність («Reliability»), але вона може бути інтерпретована і як стабільність чи стійкість («Resilience»). Нарешті за «E» стоять люди («Engineers») чи практика загалом («Engineering»).

Вперше термін SRE у його сенсі використав Ben Treynor з Google приблизно у 2003 році. В своєму інтерв’ю він описав його так:

«По суті, це те, що відбувається, коли ви просите інженера розробити операційну функцію ... Тобто SRE тут виконує роботу, яка історично виконувалася операційною командою, але з залученням інженерів (які мають досвід роботи з програмним забезпеченням), а також ставкою на те, що ці інженери одночасно хочуть і здатні замінити автоматизацію людською працею».

Google можна назвати піонерами цього руху. Вони витрачають досить багато грошей, щоб продати своє бачення SRE (landing.google.com/sre ). Інші гравці індустрії прийняли SRE на своїх власних умовах, і тлумачення терміну варіюється в дуже широких межах від компанії до компанії. Нижче я наведу ще один приклад визначення від Tammy Butow, менеджера з SRE в Dropbox:

«SRE — це інженери-програмісти, що спеціалізуються на надійності. SRE застосовує принципи комп’ютерної науки та інженерії при проектуванні і розробці комп’ютерних систем. Як правило — великих і розподілених».

Site Reliability Engineering — це, перш за все, розбудова світу онлайн-сервісів — від інфраструктурних (IaaS) і мережевих (NaaS) проектів до програмного забезпечення (SaaS) і платформ (PaaS). Це значна дисципліна, яка вимагає навичок для роботи з великими, розподіленими сайтами. Вона усуває здогадки і суперечки про те, що і коли можна запускати.

З іншого боку, SRE запроваджує унікальні метрики, такі як індикатори рівня сервісу (SLI), сервісні цілі (SLO) і дотримання угоди про рівень сервісу (SLA) для постійного контролю над надійністю вашого продукту. Зрештою, вибір відповідних метрик допомагає узгодити і направити ваші дії у разі, якщо щось піде не так, а також дає впевненість команді SRE у «здоров’ї» сервісу.

SLI — це показник рівня сервісу, тобто те, що ви вимірюєте і де відбувається вимірювання. Ось список найпоширеніших SLI:

  • Затримки
  • Пропускна здатність
  • Доступість
  • Кількість помилок
  • Стійкість

SLO — це сервісні цілі — ваша мета або поріг допустимих значень для SLI протягом обраного періоду часу.

Нарешті SLA — це угода про рівень сервісу або ваша бізнес-пропозиція клієнтам про наслідки виконання/невиконання цілей з SLO. Інакше кажучи, SLA визначає наскільки надійною повинна бути система для кінцевих користувачів. Якщо команда погоджується на 99,9% SLA, це автоматично встановлює бюджет похибки в 0,1%. Бюджет похибки — це максимально допустимий поріг помилок і збоїв.

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

Це:

  • Моніторинг і нагляд
  • Реагування на інциденти та відгуки
  • Дата центр
  • Контейнерна платформа
  • Мережа
  • Автоматизація, реліз-інжиніринг
  • Бази даних

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

SRE та DevOps

На цьому моменті ви можете запитати: «А де ж у цьому русі за надійність місце для DevOps?». Відповідь проста: SRE та DevOps працюють в тандемі. Наприклад, ось цитата з посібника Google SRE:

«Термін „DevOps“ з’явився в індустрії наприкінці 2008 року і, на момент написання цієї статті (початок 2016 року), все ще знаходиться в стані розвитку. Його основні принципи — залучення ІТ-функції в кожну фазу проектування і розробки системи, сильна залежність від автоматизації в порівнянні з людськими зусиллями, застосування інженерних практик та інструментів для вирішення операційних завдань. Вони відповідають багатьом принципам і практикам SRE.

DevOps можна розглядати як узагальнення кількох основних принципів SRE для більш широкого кола організацій, управлінських структур та персоналу. Еквівалентним чином можна було б розглядати SRE в якості конкретного впровадження DevOps з деякими ідіосинкратичними розширеннями».

DevOps фокусується на створенні «continuous delivery» і постійному тестуванні до точки впровадження програмного забезпечення. Цього можна досягти тільки гуртуванням розробників, тестувальників та операційних команд.

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

Варто додати, що швидкість поняття «delivery» й впровадження важлива ще й тому, що розробник може скоріше повертати код і виправляти помилки. DevOps створює більш жорсткі цикли зворотного зв’язку для поліпшення процесу «delivery» програмного забезпечення. Однак, ви не зможете досягти SRE без навчання. Системи постійно змінюються, тому будь-якій організації потрібно вчитися керувати складними процесами для досягнення потрібної надійності. SRE роблять це, застосовуючи практику DevOps.

Тестування в SRE

А тепер давайте обговоримо чи потрібно тестувальникам розглядати SRE в якості своєї наступної ролі, і переглядати свої обов’язки. Почнемо з декількох фактів:

  • Інженер-тестувальник знає як працює система чи функція, як вона може зламатися та як її виправити (або принаймні того, хто може її виправити).
  • Зазвичай ефективного тестувальника можна описати кількома рядками. Це допитлива людина, яка все ставить під сумнів. Вона, як правило, спеціально ламає речі. Вміє ставити себе на місце користувача та використовує контекст ситуації у якості орієнтиру.
  • Інженер SRE, у свою чергу, розуміє, як той чи інший код вписується в глобальну архітектуру компанії і намагається налаштувати всю систему максимально ефективно, підтримуючи її надійність.
  • Протягом останніх декількох років тестування програмного забезпечення змістилося з традиційного у напрямок виробництва.

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

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

Кількість випробувань, яке необхідно провести для тої чи іншої системи, залежить від вимог, але в нашому випадку це вимоги до надійності. Єдине, про що треба пам’ятати, — всі роботи з тестування проводяться проти виробничого середовища, слідуючи останнім тенденціям індустрії. (increment.com/...​ing/i-test-in-production).

Продакшн-тести, з іншого боку, проводяться в режимі реального часу одразу на веб-сервісі. За їх допомогою можна оцінити правильність роботи розгорнутої системи створеної інженерами SRE. Тут мета інженерів-тестувальників (забезпечити стабільну якість продукції) добре поєднується з цілями SRE, а їх досвід допомагає швидко ставати своїми в командах SRE. Додайте до цього повільну відмову від QA-тестування, яке ми знаємо ще з часів водоспадної моделі розробки, і перехід на безупинне тестування в DevOps. Гадаю, всі ці фактори демонструють наскільки має сенс фахівцям з тестування спробувати себе в якості SRE.

Нижче наведені деякі ключові навички для SRE (так як позиції описують зазвичай англійською, всі подані мовою оригіналу):

  • Release engineering
  • Operating systems
  • Databases
  • Cloud computing
  • Security
  • Troubleshooting
  • Customer support
  • Networking

При чому кожну з цих областей можна посилити, застосовуючи свій досвід тестування.

Традиційна галузь тестування повільно згасає разом із «Waterfall» моделлю розробки. Перехід на SRE для тестових інженерів здається цілком логічним, але я не кажу, що кожен тестувальник повинен вже змінювати свою роль. Однак, думки на цю тему можуть допомогти відповісти вам на питання «А що ж далі?»

Що у підсумку

ІТ-індустрія переповнена купою «базвордів» і трендів. Спочатку був DevOps, далі Docker, Kubernetes та RPA. Проте, перспективи SRE наразі — стати більше ніж все це. Тим паче, мова тут йде більше про людей та процеси, ніж про інструменти (Hello Agile;)). Ринок вже користується всім необхідним інструментарієм, а тому немає потреби шукати щось нове для узгодження розробки, тестування та операцій згідно принципів Site Reliability Engineering.

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

СайтКількість вакансій
Indeed5,985
Glassdoor11,097
LinkedIn2,032
Stack Overflow 1,384
Monster2,289

Насамкінець, у щорічних звітах LinkedIn за 2017, 2018 та 2019 роки SRE завжди потрапляв у топ 20 «Найперспективніших робочих місць». Тож, якщо ви зацікавились і хочете зрозуміти роль та обов’язки SRE більш детально, ознайомтеся з ресурсами нижче.

Корисні лінки

Google’s SRE Resources - landing.google.com/sre

SRE in the spotlight — youtu.be/cg8wdrm-B1g

SREcon videos — www.usenix.org/srecon

Keeping Google up and running 24/7 — youtu.be/yXI7r0_J29M

SRE at Dropbox  - youtu.be/ggizCjUCCqE

SRE at Netflix  - youtu.be/koGaH4ffXaU

DevOps Handbook — www.amazon.com/...​ganizations/dp/1942788002

The Phoenix Project — www.amazon.com/...​g-Business/dp/1942788290

The Unicorn Project — www.amazon.com/...​n-Thriving/dp/1942788762

A Practical Guide to Testing in DevOps — leanpub.com/testingindevops

Accelerate — https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339/

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Якщо під SRE ви розумієте server restart engineer то звісно для QA там ціле поле де розвернутись.

Насправді SRE робить оцей ваш весь код операбельним в продакшоні. Щоб були всякі метрики і хелсчеки і авторекавері, коли деплоїться мертвий реліз і починає смердіти в логах, і автоскейл і редандансі починаючи від інфраструктури і закінчуючи сервіс провайдерами, бо коли щось падає то пейджер дзвонить в SRE. Якщо тестувальник це все отак знаскоку осилить то не варто було йти в тестувальники in the first place.

Пришел на собеседование в SoftServ, оказалось что у них
DevOps = те человеки, кто не работают с продакшин.
SRE = те DevOps человеки, кто работает с продакшин.

PS: блин, сколько можно заниматься херней и придумывать свои интерпретации терминов, придумывать термины и пихать везде «Проект Феникс».

DevOps пишет пайплайны
SRE пишет постмортемы

Підписатись на коментарі