Терминът Site Reliability Engeneering (SRE) набира все по-голяма популярност през последните няколко години. Въпреки това съществуват доста неясноти относно това какво всъщност включват дейностите, изпълнявани от SR инженерите и често тази професия се бърка със системен администратор или DevOps.
Григорий Бурмистров, Site Reliability инженер в международната компания за разработка на персонализирани софтуерни решения DataArt, разказва повече по темата и това кои са най-често срещаните заблуди или неясноти относно професията.
SRE – термин, въведен от Google
Концепцията за Site Reliability Engeneering е въведена от Google още през 2003 г. Оттогава много компании инвестират в тази дейност и сформират собствени SRE екипи. Сред тях са големи брандове като Apple, Microsoft, Facebook, Twitter, Dropbox, Oracle, чийто бизнес успех е пряко свързан с безпроблемно функциониране на компютърните системи.
„По-широкото разпространение на SRE започна преди 4-5 години, като през последните 2 от тях списъкът на компаниите, които наемат SR специалисти, се увеличи значително. В крайна сметка, живеем във време, в което почти всеки бизнес зависи от вътрешните ИТ системи, тяхната надеждност, производителност, интеграция с външни услуги и т.н.“, коментира Григорий Бурмистров от DataArt.
Според него, задачите на SR инженерите в различните компании могат да варират и зависят от вида на самия бизнес. В този смисъл SRE, като сравнително нов подход, прилича на Agile средата, която има различни проявления в отделните компании. Въпреки това, необходимите качества, които специалистът по SR трябва да притежава, в 80% от случаите се припокриват.
SRE не означава екип по поддръжка
Концепцията на SRE предполага, че хората в екипа не се занимават само с поддръжка на системите, а са и разработчици, които пишат код и следят как работи той в реални условия. В този смисъл, тук е доста заличена границата между разработка и експлоатация.
„Една от задачите на SRE екипа е да се погрижи съответният рилийз да не се превърне в пинг-понг мач между разработчиците и DevOps инженерите, където всеки твърди, че проблемът идва от другата страна“, коментира Бурмистров и допълва: „SR инженерът непрекъснато разглежда възможностите за автоматизация и има доста широки правомощия. Всеки проблем за него е преди всичко причина за анализ. Ако този проблем се повтаря или носи след себе си високи рискове, SR инженерът може да реши да поправи нещо в самото приложение или да напише – самостоятелно или с помощта на колеги – инструмент, който да елиминира проблеми без човешка намеса“.
Казано иначе, чрез въвеждането на SRE разбираме дали има грешки в приложението, как да ги поправим и как непрекъснато да подобряваме надеждността на системата. Въпреки че отстраняването на неизправности също е отговорност на хората от SRE екипа, тяхната основна задача е да определят степента на ефективност на системата и да работят по подобряване на нейната надеждност. SRE може да се превърне в съпорт екип, само ако процесът е неправилно организиран: когато броят на проблемите расте като лавина и инженерите просто нямат време да свършат основната си работа.
„При нас в DataArt умишлено не наблягаме на съпорт дейностите, тъй като смятаме, че в SRE концепцията има съществени преимущества, от които бизнесът ни би извлякъл множество ползи. Поради тази причина, съпорт функциите на SRE екипите са сведени до минимум за сметка на функциите, свързани с контрол и превенция“, споделя Григорий Бурмистров.
SR инженерът – разработчик или DevOps?
SRE е опит да се създаде съвместимост между тези две роли. Инженерите, които се занимават със Site Reliability, разбират добре системата, знаят как да се задълбочат “под повърхността” и са готови да пренапишат лошия код. „Но в тази роля има и елементи на DevOps: SRE трябва да разбере как работят сървърите, на които е разположена системата, как се скалира системата, как се разпределя натоварването и т.н.“, разяснява Бурмистров.
SR инженерите са необходими предимно при работа в големи проекти на предприятия със сложни, високонатоварени приложения. Те са тези, които знаят как се държи системата в реални условия, особено ако нещо се обърка – например – с мрежовата връзка или базата данни. Това знание е необходимо не само за бързо стабилизиране на приложението, но и за извършване на нужните промени в изходния код.
Съществуват ли ясни критерии за измерване на надеждността?
Първото нещо, което SR специалистът прави, е въвеждането на показатели във всяка система, които могат да варират от проект до проект. Според Григорий Бурмистров, е важно да не прекаляваме с тях и да не измерваме това, което не ни интересува. Например, количеството дисково пространство на сървъра и натоварването на процесора влияят върху работата, но не отговарят на никой от важните въпроси за нас. SR инженерите не се интересуват от технически показатели, а от Service Level Indicators (индикатори за нивото на обслужване или още SLI – друг важен термин), а това са бизнес метрики. „Системата обслужва по-добре клиентите не когато процесорът е по-малко натоварен, а когато е в състояние да обработва повече заявки, без да жертва качеството. Само чрез измерване на критични за бизнеса индикатори можем да започнем процеса на повишаване на надеждността“, разяснява той.
Освен това, SR инженерите може да се окажат ключови фигури при преговорите с бизнеса, тъй като те са в състояние да обяснят чрез количествените показатели колко надеждна е системата, какви пречки са установени и колко ще струва да се елиминират. Заедно с представителите на бизнеса тези специалисти би трябвало да определят т. нар. Service Level Objectives (SLO), т.е. целите за нивото на обслужване, които да бъдат приемливи показатели за надеждност.
Образование и квалификация
Концепцията на SRE е все още нова и поради тази причина на пазара на труда почти няма готови специалисти или обучителни програми, посветени конкретно на това направление. Затова за тази роля биха били подходящи разработчици, владеещи Python или Java или пък DevOps инженери. За щастие, обхватът на задачите е много широк – от наблюдение и сигнализиране за проблеми (типични задачи на DevOps) до комплексно отстраняване на неизправности, което може да се направи от опитни разработчици.
„SRE е област, граничеща с програмирането и DevOps, а намирането на човек с богат опит в двете сфери е много трудно. Следователно, не се очаква познаване на всички процеси и инструменти, тъй като SRE ви позволява да се научите, като работите по конкретни задачи. Ето защо, професията дава перспективи не само за Senior инженери, но и за разработчици или DevOps специалисти с по-малко опит“, разяснява Бурмистров от DataArt.
Според него, трудно можем да говорим за рутина в работата на SR инженера, тъй като тук не става дума за безкраен набор от повтарящи се операции. „Най-общо казано – дейностите са свързани с три неща: избягване на проблема, разрешаването му, ако възникне такъв, и анализ на причините, които са довели до него. За SR инженера разрешаването на проблема е само началото: след това той трябва да разбере какво е причинило инцидента, да го оцени и да реши как да предотврати това да се случи в бъдеще“.
Екипни модели
Що се отнася до формирането на екипи – обикновено се ползват два различни подхода. В първия случай SR инженерът работи в екип, заедно с разработчици и QA специалисти. Членовете на този екип могат да бъдат в състояние на продуктивен творчески конфликт, който им помага да не правят опасни компромиси. Друг подход е целият екип на SRE да работи по проекта. „Ние в DataArt използваме втория подход в проекти, които са преминали етапа на активно развитие, където системата е относително стабилна. Такава система може да бъде активно управлявана от клиента“, разяснява Бурмистров.
Какви са перспективите пред развитието на професията?
Прогнозите сочат, че търсенето на специалисти за SRE екипи ще се повиши през следващите три години. SRE е в състояние да се превърне в стабилен източник на доходи за всяка компания, насочена към големи и сложни бизнес проекти. Системите продължават да се усложняват, общите разходи се увеличават. Ето защо, ролята на SRE през следващите години може да бъде сравнима с наемането на QA Automation преди 10 години или DevOps преди пет години, смята Бурмистров .
За DevOps инженерите и разработчиците SRE е чудесна възможност да разберат системите в дълбочина, тъй като понастоящем почти никой не може да си позволи просто да пише код, без да мисли за неговото бъдеще. Освен това, инструментите, предназначени за работа, по презумпция са програми с отворен код, което означава, че натрупаният опит може лесно да бъде прехвърлен към други проекти и компании.
