Кариери

Site reliability инженерът и неговата ключова роля

CIO Media

Скот Кери, InfoWorld

Принципите на Site reliability инженеринга (SRE), разработени първоначално от Google, днес имат важна роля в самото сърце на devops

Светът се премести онлайн и с това стабилността на уебсайтовете, облачните приложния и инфраструктури се превърна в ключов елемент за бизнеса - за всичко от онлайн търговска дейност, през световните банки до търсачките. Промени се начинът, по който управляваме системите и тяхното натоварване. Днес рядко мислим за скъпи, високотехнологични, високоефективни сървъри. Вместо това си представяме наредени един до друг масови сървъри, събрани в едно чрез виртуализация, с разпределена софтуерна инфраструктура, която гарантира непрекъсната работа. Фокусът се премести от хардуерно към софтуерно дефинирана инфраструктура и от непоследователни и пълни с грешки ръчни процеси към непрекъснати, надеждни и повторяеми автоматизирани задачи.

SRE отговаря за поддържането на тази програмируема инфраструктура и максимализирането на наличността на работните процеси, които се осъществяват върху нея. Длъжността на Site reliability инженера се появява за пръв път в Google, когато в началото на века компанията иска да предефинира взаимоотношения между софтуерните разработчици и оперативните служители и да им помогне да работят заедно в изграждането на стабилна, гъвкава система с непрекъснати подобрения и автоматизация като основни нейни принципи.

Какво е SR инженер?

В същността си SR инженерът прилага принципите на софтуерното инженерство върху инфраструктурни и оперативни проблеми с цел да създаде надеждни системи с възможност за лесно разрастване.

"Принципно това е, когато помолите софтуерен инженер да проектира оперативна функция", както често цитират Бен Трейнър, вицепрезидент в Google и кръстник на SRE.

Една от главните отговорности на SR инженера е да установи прагове на нивото на услугите, често под формата на цели на нивото на услугите (Service-Level Objectives, или SLOs), с помощта на които се дава информация дали нова версия е одобрена за пуск. Ключовият момент са заветните "пет деветки", или 99.999% време на непрекъсната работа. Колкото по-добро е това време, толкова повече яки неща могат да пускат в експлоатация разработчиците и толкова повече спокоен сън имат SR инженерите, което води до взаимно полезно сътрудничество между отделите, далеч от миналото на враждебност между разработчици и оперативни служители.

SRE функцията обикновено се измерва с ключови показателите за стабилност, сред които работа на системата, наличност, латентност, производителност, контрол, планиране на капацитета и реакция на извънредни ситуации.

Основни отговорности на SR инженера

Всеки добър SR инженер е обсебен от едно определено нещо - автоматизацията. Както пише в блог пост Джейсън Куолмън, SR инженер в New Relic, "голяма част от тази работа е да се мисли за неефективните и времеемки неща, които хората извършват, и премахването им при първа възможност. Вместо да си затваряте очите за това, казвате "Ще отделя време да автоматизирам тази досадна задача още сега, за да няма нужда никой повече да се занимава с нея".

Друг ключов елемент от работата на SR инженера е т. нар. инженеринг на версиите, който включва дефиниране на добри практики за гарантиране последователността и повторяемостта на нови софтуерни версии.

"Инженерите по новите версии имат сериозни (дори експертни) познания за управление на изходния код, компилатори, конфигурационни езици, автоматизирани инструменти, мениджъри на пакети и инсталатори. Сред уменията им са задълбочени познания в различни области: разработване, управление на конфигурирането, интеграция на тестове, системна администрация и клиентска поддръжка", пише Дина Макнът, технически програмен мениджър в Google, в книгата Site Reliability Engineering от 2016 г. на издателство O'Reilly със съавтори Дженифър Петоф, Ниал Ричард Мърфи, Крис Джоунс и Бетси Бейър от Google.

След това имаме реактивната част на ролята, която включва алармиране, да си на повикване и отстраняване на проблеми, както и реакция и последващ анализ на извънредни ситуации и инциденти.

Важно е SR инженерите да знаят как най-добре да следят системите и да реагират при възникване на проблем, непрекъснато да пишат и пренаписват сценарии за реакция с цел намаляване на времето за поправка на всевъзможни проблеми. В Google това включва документиране на инцидент, вникване във всички основни причини за него и внедряване на действия за бъдеща превенция.

"Написването на последващ анализ не е наказание. То е възможност за цялата компания да научни нещо ново", пишат Джон Луни и Сю Ледър от Google в глава от книгата.

SR срещу devops инженери

Сигурно си мислите, че това звучи много като devops, но ако вземем терминологията, длъжността SR инженер предхожда тази на devops колегата с около пет години. И двете се основават на подобни принципи с има малка, но важна разлика. И двата начина на работа включват премахването на бариерите между разработчици и оперативни служители. И на двамата целта е да се увеличи скоростта на разработващите екипи, като същевременно се поддържа устойчивостта на тези услуги.

Разликата е, че devops инженерите се фокусират върху поддържането на непрекъснато генериране на краен продукт и скорост на разработка, докато SR инженерите отговарят за надеждността и автоматизация в рамките на жизнения цикъл на софтуера, с акцент върху успешния пуск и контрол на новите версии и поддържане на добрата работа на софтуерно дефинираната инфраструктура. SR инженерът има съществена функция в по-обхватния инженерен екип - гарантиране, че на масата има място за специалист, отговарящ за изграждането на стабилни системи.

Както казва Джейн Грол от Devops Institute, "Devops отговаря за управлението на непрекъснатото генериране на краен продукт до момента на внедряване, докато SR инженерът се фокусира върху непрекъснатата работа при клиента".

История на SRE в Google

Проследяването на SRE принципите до техните корени в Google в началото на века предлага основен урок по дисциплината. "Когато дойдох в Google, имах късмета да бъда част от екип, в който участваха и софтуерни инженери, готови да използват софтуер за разрешаване на досега ръчно изпълнявани задачи. Затова, когато бе време да се формира екип за тази оперативна задача, бе естествено да се възприеме подходът "всичко може да се третира като софтуерен проблем", твърди Бен Трейнър във вътрешнофирмения блог на Google.

"Следователно SR инженерът извършва принципно работа, която е за оперативен екип, но използвайки инженери със софтуерни познания и разчитайки на факта, че те имат присъщата склонност и способности да заместят ръчния труд с автоматизация", добавя Трейнър.

Google мисли сериозно и как да формира един SRE екип. Всички SR инженери в Google трябва да бъдат или Google софтуерни инженери, или "да са кандидати с близки до тяхната квалификация". Те трябва да притежават умения в управлението на инфраструктури, най-вече Unix system internals and networking (Layer 1 to Layer 3).

Квалификацията на SR инженера е различна в различните компании, но що се отнася до основните принципи, подходът на Google е добра отправна точка. Детайлите зависят от нуждите на бизнеса, установените процеси и технологии, вече съществуващи в компанията.

Длъжностна характеристика и заплата на SR инженер
SR инженерите обикновено прекарват половината от времето си в изпълняването на традиционни оперативни задачи като това да са на повикване и да реагират за разрешаване на проблеми. Другата половина е фокусирана върху разработването на софтуер, който да прави основните системи по-устойчиви, автоматизирани и самолекуващи се с времето. Затова тази позиция изисква смесица от софтуерни инженерингови и оперативни познания. Добрият SR инженер е организиран, спокоен под напрежение и разрешаващ проблеми. SRE мениджърите отговарят за ефективността на екипа, стратегията и оптимизацията.

Какво става обаче във фирмите, където тази позиция не съществува? В доклада на O'Reilly "Какво е SRE?" Курт Андерсън от LinkedIn и Крейг Зебеник от Split (доставчик на софтуер за управление на версиите) препоръчват да се намери "екип от разработчици, мотивиран за промяна, и в него да се внедри малък SRE екип или човек. С времето може да използвате успехите си тук като положителен пример за други екипи".

Средната годишна заплата на SR инженера е около $130 000 в САЩ и £76 000 във Великобритания.

SRE ресурси

Ресурси по темата как да изградим SRE умения има много - от сертификати на DevOps Institute до книги и онлайн ресурси от O'Reilly, Microsoft и Google. Спомената по-горе книга от 550 страници Site Reliability Engineering на Дженифър Петоф, Ниал Ричард Мърфи, Крис Джоунс и Бетси Бейър е основен източник по темата. Тя е налична и онлайн безплатно от Google.

Други по-нови книги по темата са Training Site Reliability Engineers на Дженифър Петоф, Джейси ван Уинкъл и Престън Йошиока; What Is SRE? на Курт Андерсън и Крейг Зебеник; Seeking SRE на Дейвид Бленк-Еделман; The Site Reliability Workbook на Бетси Бейър, Ниал Ричард Мърфи, Дейвид Ренсин, Кент Кавахара и Стивън Торн.

O'Reilly разполага и с богата библиотека от онлайн материали, видео- и електронни книги по темата, представени под заглавието SRE Essentials от бившия Google SR инженер Лиз Фон-Джоунс.

Гигантът в онлайн образованието Coursera предлага няколко курса, сред които популярният Site Reliability Engineering: Measuring and Managing Reliability на Google Cloud Training. Този курс може да намерите още в Pluralsight, както и курса за начинаещи Site Reliability Engineering (SRE): The Big Picture от Елтън Стоунмън. Linux Foundation предлага курса DevOps and SRE Fundamentals: Implementing Continuous Delivery.

Базираната във Великобритания компания Jellyfish Training предлага различни двудневни частни обучения за SRE Foundation (SREF).

Превод и редакция Юлия Уршева

X