Vebinarda zəif səs var, ona görə də onu transkripsiya etdik.
Mənim adım Medvedev Eduarddır. Bu gün mən SRE-nin nə olduğu, SRE-nin necə ortaya çıxması, SRE mühəndisləri üçün iş meyarları, bir az etibarlılıq meyarları, bir az da onun monitorinqi haqqında danışacağam. Yuxarıdan keçəcəyik, çünki bir saat ərzində çox şey deyə bilməzsiniz, lakin mən sizə əlavə araşdırma üçün materiallar verəcəyəm və hamımız sizi burada gözləyirik. . Yanvarın sonunda Moskvada.
Əvvəlcə SRE-nin nə olduğundan danışaq - Saytın Etibarlılığı Mühəndisliyi. Və necə ayrı bir mövqe kimi, ayrıca bir istiqamət kimi meydana çıxdı. Hər şey ənənəvi inkişaf dairələrində Dev və Ops-un ümumiyyətlə iki tamamilə fərqli məqsədi olan iki tamamilə fərqli komanda olması ilə başladı. İnkişaf komandasının məqsədi yeni funksiyaları yaymaq və biznesin ehtiyaclarını ödəməkdir. Əməliyyat komandasının məqsədi hər şeyin işlədiyinə və heç bir şeyin pozulmadığına əmin olmaqdır. Aydındır ki, bu məqsədlər bir-biri ilə birbaşa ziddiyyət təşkil edir: hər şeyin işləməsi və heç bir şeyin pozulmaması üçün mümkün qədər az yeni funksiyaları işə salın. Bu səbəbdən indi DevOps adlanan metodologiyanın həll etməyə çalışdığı bir çox daxili münaqişələr var.
Problem ondadır ki, bizdə DevOps-un dəqiq tərifi və DevOps-un dəqiq tətbiqi yoxdur. 2 il əvvəl Yekaterinburqda bir konfransda çıxış etdim və indiyə qədər DevOps bölməsi “DevOps nədir” hesabatı ilə başladı. 2017-ci ildə Devops-un demək olar ki, 10 yaşı var, amma biz hələ də bunun nə olduğunu mübahisə edirik. Və bu, Google-un bir neçə il əvvəl həll etməyə çalışdığı çox qəribə bir vəziyyətdir.
2016-cı ildə Google “Site Reliability Engineering” adlı kitab buraxdı. Və əslində, SRE hərəkatı məhz bu kitabla başladı. SRE, müəyyən bir şirkətdə DevOps paradiqmasının xüsusi tətbiqidir. SRE mühəndisləri sistemlərin etibarlı işləməsini təmin etməyə sadiqdirlər. Onlar əsasən tərtibatçılardan, bəzən güclü inkişaf keçmişi olan idarəçilərdən gəlirlər. Və onlar sistem inzibatçılarının əvvəllər etdiklərini edirlər, lakin kod baxımından sistemin inkişafı və biliklərinin güclü olması ona gətirib çıxarır ki, bu insanlar adi inzibati işlərə meylli deyil, avtomatlaşdırmaya meyllidirlər.
Belə çıxır ki, SRE komandalarında DevOps paradiqması struktur problemlərini həll edən SRE mühəndislərinin olması ilə həyata keçirilir. Budur, Dev və Ops arasında insanların 8 ildir danışdıqları eyni əlaqə. SRE-nin rolu memarın roluna bənzəyir ki, yeni başlayanlar SRE-yə çevrilmir. Karyerasının başlanğıcında olan insanlar hələ heç bir təcrübəyə malik deyillər və lazımi bilik genişliyinə malik deyillər. Çünki SRE tam olaraq nəyin və nə vaxt səhv gedə biləcəyinə dair çox mükəmməl bilik tələb edir. Buna görə də, burada, bir qayda olaraq, həm şirkət daxilində, həm də xaricdə bir növ təcrübə lazımdır.
SRE və devops arasındakı fərqin təsvir edilib-edilməyəcəyini soruşurlar. O, indicə təsvir edilmişdir. SRE-nin təşkilatdakı yerindən danışmaq olar. Klassik DevOps yanaşmasından fərqli olaraq, burada əməliyyatlar hələ də ayrıca bir şöbədir, SRE inkişaf komandasının bir hissəsidir. Onlar məhsulun hazırlanmasında iştirak edirlər. Hətta belə bir yanaşma var ki, SRE bir inkişaf etdiricidən digərinə keçən bir roldur. Onlar, məsələn, UX dizaynerləri, tərtibatçıların özləri və bəzən məhsul menecerləri ilə eyni şəkildə kod araşdırmalarında iştirak edirlər. SRE-lər eyni səviyyədə fəaliyyət göstərir. Onların təsdiqinə ehtiyacımız var, onların nəzərdən keçirilməsinə ehtiyacımız var ki, hər yerləşdirmə üçün SRE deyir: “Yaxşı, bu yerləşdirmə, bu məhsul etibarlılığa mənfi təsir göstərməyəcək. Əgər belə olarsa, o, bəzi məqbul hədlər daxilində olacaq”. Bu barədə də danışacağıq.
Müvafiq olaraq, SRE kodu dəyişdirmək üçün veto hüququna malikdir. Və ümumiyyətlə, bu, SRE-nin səhv həyata keçirildiyi təqdirdə bəzi kiçik münaqişələrə səbəb olur. Saytın Etibarlılığı Mühəndisliyi ilə bağlı eyni kitabda bir çox hissə, hətta bir hissəsi bu münaqişələrdən necə qaçınmağı izah edir.
Onlar SRE-nin informasiya təhlükəsizliyi ilə necə əlaqəli olduğunu soruşurlar. SRE birbaşa informasiya təhlükəsizliyi ilə məşğul deyil. Əsasən, böyük şirkətlərdə bunu fərdlər, testçilər, analitiklər edir. Lakin SRE onlarla o mənada qarşılıqlı əlaqədə olur ki, bəzi əməliyyatlar, bəzi öhdəliklər, təhlükəsizliyə təsir edən bəzi yerləşdirmələr də məhsulun mövcudluğuna təsir göstərə bilər. Buna görə də, SRE bütövlükdə hər hansı komanda, o cümlədən təhlükəsizlik qrupları, o cümlədən analitiklər ilə qarşılıqlı əlaqəyə malikdir. Buna görə də, SRE-lərə əsasən DevOps tətbiq etməyə çalışarkən ehtiyac duyulur, lakin eyni zamanda tərtibatçıların üzərinə düşən yük çox böyük olur. Yəni, inkişaf komandasının özü artıq əməliyyatlara cavabdeh olmaları lazım olduğu faktının öhdəsindən gələ bilməz. Və ayrı bir rol var. Bu rol büdcədə nəzərdə tutulub. Bəzən bu rol komandanın ölçüsündə qoyulur, ayrı bir şəxs görünür, bəzən tərtibatçılardan biri olur. Komandada ilk SRE belə görünür.
SRE-dən təsirlənən sistemin mürəkkəbliyi, əməliyyatın etibarlılığına təsir edən mürəkkəblik zəruri və təsadüfidir. Zəruri mürəkkəblik, məhsulun mürəkkəbliyinin yeni məhsul xüsusiyyətlərinin tələb etdiyi dərəcədə artmasıdır. Təsadüfi mürəkkəblik sistemin mürəkkəbliyinin artmasıdır, lakin məhsulun xüsusiyyəti və biznes tələbləri buna birbaşa təsir etmir. Belə çıxır ki, ya tərtibatçı hardasa səhv edib, ya da alqoritm optimal deyil, ya da xüsusi ehtiyac olmadan məhsulun mürəkkəbliyini artıran bəzi əlavə maraqlar təqdim olunur. Yaxşı bir SRE həmişə bu vəziyyəti kəsməlidir. Yəni, təsadüfi əlavə səbəbindən çətinliyin artdığı hər hansı bir öhdəlik, hər hansı bir yerləşdirmə, istənilən çəkmə sorğusu bloklanmalıdır.
Sual ondan ibarətdir ki, nə üçün sadəcə mühəndisi, çox biliyə malik sistem administratorunu komandaya işə götürməyək. Bizə deyilir ki, mühəndis rolunda olan bir tərtibatçı ən yaxşı kadr həlli deyil. Mühəndis rolunda olan bir tərtibatçı həmişə ən yaxşı kadr həlli deyil, amma burada əsas məqam ondan ibarətdir ki, Ops ilə məşğul olan bir tərtibatçı avtomatlaşdırma üçün bir az daha çox istəyi var, bir az daha çox bilik və bacarıqlara malikdir. bu avtomatlaşdırma. Müvafiq olaraq, biz nəinki bəzi xüsusi əməliyyatlar üçün vaxtı, nəinki rutini, həm də MTTR (Bərpa üçün Orta Vaxt, bərpa müddəti) kimi vacib biznes parametrlərini azaldır. Beləliklə, biz də bir az sonra bu barədə danışacağıq, təşkilata pul yığırıq.
İndi SRE işinin meyarları haqqında danışaq. Və ilk növbədə etibarlılıq haqqında. Kiçik şirkətlərdə və startaplarda tez-tez belə olur ki, insanlar xidmət yaxşı yazılsa, məhsul yaxşı və düzgün yazılsa, işləyəcək, pozulmayacaq. Budur, yaxşı kod yazırıq, buna görə də pozulacaq bir şey yoxdur. Kod çox sadədir, pozulacaq heç nə yoxdur. Bunlar bizim testlərə ehtiyacımız olmadığını söyləyən eyni insanlardır, çünki baxın, bunlar üç VPI üsuludur, niyə narahat olursunuz?
Bütün bunlar, əlbəttə ki, yanlışdır. Və bu insanlar çox vaxt praktikada belə kodla dişlənirlər, çünki şeylər pozulur. İşlər bəzən ən gözlənilməz şəkildə pozulur. Bəzən insanlar deyirlər ki, yox, heç vaxt olmayacaq. Və bu, hər zaman olur. Kifayət qədər tez-tez olur. Və buna görə də heç kim heç vaxt 100% əlçatanlıq üçün səy göstərmir, çünki 100% mövcudluq heç vaxt baş vermir. Bu normadır. Və buna görə də, bir xidmətin mövcudluğu haqqında danışarkən, biz həmişə doqquzdan danışırıq. 2 doqquz, 3 doqquz, 4 doqquz, 5 doqquz. Bunu dayanma vaxtına çevirsək, məsələn, 5 doqquz, onda bu, ildə 5 dəqiqədən bir az çox fasilədir, 2 doqquz 3,5 günlük fasilədir.
Amma aydındır ki, müəyyən məqamda POI-də azalma, investisiya gəliri var. İki doqquzdan üç doqquza keçmək 3 gündən çox daha az dayanma müddəti deməkdir. Dörd doqquzdan beşə keçmək, dayanma müddətini ildə 47 dəqiqə azaldır. Və belə çıxır ki, biznes üçün bu, kritik olmaya bilər. Və ümumiyyətlə, tələb olunan etibarlılıq texniki məsələ deyil, ilk növbədə, bu, biznes məsələsidir, məhsul məsələsidir. Məhsulun istifadəçiləri üçün hansı səviyyədə dayanma müddəti məqbuldur, onlar nə gözləyirlər, nə qədər ödəyirlər, məsələn, nə qədər pul itirirlər, sistem nə qədər pul itirir.
Burada vacib bir sual qalan komponentlərin etibarlılığının nə olmasıdır. Çünki etibarlılığı 4 doqquz olan smartfonda 5 ilə 2 doqquz arasındakı fərq görünməyəcək. Kobud desək, xidmətinizdə olan smartfonda ildə 10 dəfə nəsə xarab olarsa, çox güman ki, 8 dəfə OS tərəfində nasazlıq baş verib. İstifadəçi buna öyrəşib və ildə bir dəfəyə fikir verməyəcək. Etibarlılığın artırılması və mənfəətin artırılması qiymətini əlaqələndirmək lazımdır.
Sadəcə SRE haqqında kitabda 4 doqquzdan 3 doqquza yüksəlməyin yaxşı bir nümunəsi var. Belə çıxır ki, mövcudluğun artması 0,1%-dən bir qədər azdır. Xidmətin gəliri ildə 1 milyon dollardırsa, gəlir artımı 900 dollardır. Mövcudluğu doqquz artırmaq bizə ildə 900 dollardan az başa gəlirsə, artımın maliyyə mənası var. Əgər bu, ildə 900 dollardan çox başa gəlirsə, bunun artıq mənası yoxdur, çünki gəlirin artması sadəcə olaraq əmək xərclərini və resurs xərclərini kompensasiya etmir. Bizə isə 3 doqquz kifayət edəcək.
Bu, əlbəttə ki, bütün sorğuların bərabər olduğu sadələşdirilmiş bir nümunədir. 3 doqquzdan 4 doqquza qədər getmək olduqca asandır, lakin eyni zamanda, məsələn, 2 doqquzdan 3-ə keçmək artıq 9 min dollar qənaətdir, maliyyə mənasında ola bilər. Təbii ki, reallıqda sorğunun qeydə alınmaması səhifənin göstərilməməsindən daha pisdir; sorğuların çəkisi fərqlidir. İşgüzar nöqteyi-nəzərdən onların tamamilə fərqli meyarları ola bilər, amma yenə də, bir qayda olaraq, hər hansı xüsusi xidmətlərdən danışmırıqsa, bu kifayət qədər etibarlı bir yaxınlaşmadır.
Xidmət üçün arxitektura həllini seçərkən SRE-nin koordinatorlardan biri olub-olmaması ilə bağlı sual aldıq. Mövcud infrastruktura inteqrasiya baxımından deyək ki, onun sabitliyində itki olmasın. Bəli, SRE-lər, sorğuları cəlb edən, öhdəlikləri yerinə yetirən, buraxılışlar arxitekturaya, yeni xidmətlərin, mikroservislərin tətbiqinə, yeni həllərin tətbiqinə təsir göstərir. Niyə əvvəl dedim ki, təcrübə lazımdır, ixtisas lazımdır. Əslində, SRE istənilən memarlıq və proqram həllində bloklayan səslərdən biridir. Müvafiq olaraq, bir mühəndis kimi SRE, ilk növbədə, nəinki anlamalı, həm də bəzi xüsusi qərarların etibarlılığa, sabitliyə necə təsir edəcəyini anlamalı və bunun biznes ehtiyacları ilə necə əlaqəli olduğunu və hansı nöqteyi-nəzərdən məqbul ola biləcəyini başa düşməlidir. hansı yox.
Buna görə də, indi SRE-də ənənəvi olaraq SLA (Service Level Agreement) kimi müəyyən edilən etibarlılıq meyarları haqqında danışmaq olar. Çox güman ki, tanış termindir. SLI (Xidmət Səviyyəsi Göstəricisi). SLO (Xidmət Səviyyəsi Məqsədi). Xidmət Səviyyəsi Müqaviləsi bəlkə də simvolik bir termindir, xüsusən də şəbəkələrlə, provayderlərlə, hostinqlə işləmisinizsə. Bu, bütün xidmətinizin performansını, cəzaları, səhvlərə görə bəzi cəzaları, ölçüləri, meyarları təsvir edən ümumi razılaşmadır. Və SLI mövcudluq metrikasının özüdür. Yəni, SLI nə ola bilər: xidmətdən cavab müddəti, faizlə səhvlərin sayı. Bir növ fayl hostinqidirsə, bu, bant genişliyi ola bilər. Tanınma alqoritmlərinə gəldikdə, göstərici, məsələn, hətta cavabın düzgünlüyü ola bilər. SLO (Service Level Objective) müvafiq olaraq SLI göstəricisinin, onun dəyərinin və müddətinin birləşməsidir.
Deyək ki, SLA belə ola bilər. Xidmət il ərzində 99,95% mövcuddur. Və ya 99 kritik dəstək bileti rübdə 3 saat ərzində bağlanacaq. Və ya sorğuların 85%-i hər ay 1,5 saniyə ərzində cavab alacaq. Yəni yavaş-yavaş başa düşürük ki, səhvlər və uğursuzluqlar olduqca normaldır. Bu, məqbul bir vəziyyətdir, biz bunu planlaşdırırıq, hətta müəyyən dərəcədə buna ümid edirik. Yəni, SRE səhv edə bilən sistemlər qurur, səhvlərə normal cavab verməli, onları nəzərə almalıdır. Mümkün olduqda, səhvləri elə idarə etməlidirlər ki, istifadəçi ya onları görməsin, ya da xəbərdar etsin, lakin bir növ həll yolu var, bunun sayəsində hər şey tamamilə yıxılmayacaq.
Məsələn, YouTube-a bir video yükləsəniz və YouTube onu dərhal çevirə bilmirsə, video çox böyükdürsə, format optimal deyilsə, sorğu təbii olaraq fasilə ilə uğursuz olmayacaq, YouTube 502 xətası verməyəcək. , YouTube deyəcək: “Hər şeyi yaratdıq, videonuz emal olunur. Təxminən 10 dəqiqəyə hazır olacaq”. Bu, nə vaxtsa bunu etmisinizsə, məsələn, front-end inkişafından tanış olan zərif deqradasiya prinsipidir.
Etibarlılıqla, səhvlərlə, gözləntilərlə işləmək üçün çox vacib olan növbəti danışacağımız terminlər MTBF və MTTR-dir. MTBF uğursuzluqlar arasındakı orta vaxtdır. MTTR Bərpa üçün Orta Vaxt, bərpa üçün orta vaxt. Yəni, xətanın aşkar edildiyi andan, xətanın göründüyü andan xidmətin tam normal işləməsinə qədər nə qədər vaxt keçib. MTBF əsasən kod keyfiyyəti üzərində işləməklə müəyyən edilir. Yəni, SRE-lərin “yox” deyə bilməsi. Və bütün komandanın anlayışına ehtiyacınız var ki, SRE “yox” deyəndə bunu zərərli olduğu üçün deyil, pis olduğu üçün deyil, əks halda hər kəs əziyyət çəkəcəyi üçün deyir.
Yenə də tez-tez istinad etdiyim kitabda çoxlu məqalələr, çoxlu üsullar, bir çox yol var, digər tərtibatçıların SRE-yə nifrət etməyə başlamamasına necə əmin olmaq olar. MTTR, əksinə, SLO-larınız (Xidmət Səviyyəsi Məqsədi) üzərində işləmək haqqındadır. Və bu, əsasən avtomatlaşdırmadır. Çünki, məsələn, bizim SLO rübdə 4 doqquz iş vaxtıdır. Bu o deməkdir ki, 3 ay ərzində biz 13 dəqiqə dayanmağa icazə verə bilərik. Və belə çıxır ki, MTTR 13 dəqiqədən çox ola bilməz. 13 dəqiqə ərzində ən azı 1 fasiləyə cavab versək, bu o deməkdir ki, biz artıq rüb üçün bütün büdcəni tükətmişik. Biz SLO-nu pozuruq. Bir qəzaya reaksiya vermək və düzəltmək üçün 13 dəqiqə bir maşın üçün çox şeydir, lakin bir insan üçün çox qısadır. Çünki insan xəbərdarlıq alana qədər, reaksiya verənə qədər, xətanı başa düşənə qədər artıq bir neçə dəqiqə keçir. Bir insan bunu necə düzəltməli, dəqiq nəyi düzəltməli, nə etməli olduğunu başa düşənə qədər, bu daha bir neçə dəqiqədir. Və əslində, göründüyü kimi serveri yenidən başladın və ya yeni bir node qaldırmağınız lazım olsa belə, əl ilə MTTR artıq təxminən 7-8 dəqiqədir. Prosesi avtomatlaşdırarkən, MTTR çox vaxt saniyəyə, bəzən millisaniyələrə çatır. Google adətən millisaniyələrdən danışır, amma reallıqda təbii ki, hər şey o qədər də yaxşı deyil.
İdeal olaraq, SRE öz işini demək olar ki, tamamilə avtomatlaşdırmalıdır, çünki bu, MTTR-ə, onun ölçülərinə, bütün xidmətin SLO-ya və müvafiq olaraq biznes mənfəətinə birbaşa təsir göstərir. Vaxt keçibsə, bizdən SRE-nin günahkar olub-olmaması soruşulur. Xoşbəxtlikdən heç kim günahkar deyil. Və bu, balmeless postmortem adlanan ayrı bir mədəniyyətdir, bu gün haqqında danışmayacağıq, ancaq Slurm-da təhlil edəcəyik. Bu çox maraqlı mövzudur, haqqında çox danışmaq olar. Kobud desək, hər rüb üçün ayrılan vaxt keçibsə, onda azacıq hamının günahı var, bu o deməkdir ki, hamını günahlandırmaq məhsuldar deyil, bunun əvəzinə, bəlkə də kimisə qınamayaq, vəziyyəti düzəldək, əlimizdə olanla işləyək. Təcrübəmə görə, bu yanaşma əksər komandalar üçün, xüsusən də Rusiyada bir qədər yaddır, lakin məntiqlidir və çox yaxşı işləyir. Buna görə də məqalənin və ədəbiyyatın sonunda bu mövzuda oxuya biləcəyinizi tövsiyə edəcəm. Və ya Slurm SRE-ə gəlin.
İcazə ver izah edim. Əgər hər rüb üzrə SLO vaxtı keçibsə, dayanma müddəti 13 dəqiqə yox, 15 dəqiqə olubsa, bunun günahkarı kim ola bilər? Əlbəttə ki, SRE günahkar ola bilər, çünki o, açıq şəkildə bir növ pis öhdəlik və ya yerləşdirmə etdi. Məlumat mərkəzinin administratoru bunda günahkar ola bilər, çünki o, bir növ plansız texniki xidmət göstərmiş ola bilər. Əgər məlumat mərkəzinin inzibatçısı bunda günahkardırsa, o zaman SLO-nu koordinasiya edən zaman texniki xidmət hesablamayan Ops-dan olan şəxs günahkardır. Menecer, texniki direktor və ya məlumat mərkəzi müqaviləsini imzalayan və məlumat mərkəzinin SLA-nın tələb olunan fasilələr üçün nəzərdə tutulmamasına diqqət yetirməyən kimsə bunun üçün günahkardır. Buna görə də, bu vəziyyətdə hamı yavaş-yavaş günahkardır. Bu isə o deməkdir ki, bu vəziyyətdə günahı kiminsə üstünə atmağın mənası yoxdur. Amma təbii ki, düzəldilməlidir. Buna görə də ölümdən sonra əməliyyatlar var. Əgər siz, məsələn, GitHub postmortems oxuyursunuzsa və bu, hər bir halda çox maraqlı, kiçik və gözlənilməz bir hekayədirsə, onu əvəz edə bilərsiniz ki, heç kim bu konkret şəxsin günahkar olduğunu demir. Günah həmişə konkret qeyri-kamil proseslərin üzərinə qoyulur.
Gəlin növbəti suala keçək. Avtomatlaşdırma. Digər kontekstlərdə avtomatlaşdırma haqqında danışarkən, mən tez-tez bir tapşırığı avtomatlaşdırmaq üçün əslində qənaət etdiyinizdən daha çox vaxt ayırmadan nə qədər işləyə biləcəyinizi göstərən cədvələ müraciət edirəm. Çıxış var. Məsələ ondadır ki, SRE-lər tapşırığı avtomatlaşdırdıqda, onlar nəinki vaxta qənaət edirlər, həm də pula qənaət edirlər, çünki avtomatlaşdırma MTTR-ə birbaşa təsir göstərir. Onlar, belə demək mümkünsə, işçilərin və tərtibatçıların mənəviyyatına qənaət edirlər ki, bu da tükənməz bir mənbədir. Rutini azaldırlar. Və bütün bunlar işə və nəticədə biznesə müsbət təsir göstərir, hətta vaxt xərcləri baxımından avtomatlaşdırmanın mənası yoxdur.
Əslində, demək olar ki, həmişə var və SRE rolunda bir şeyin avtomatlaşdırılmaması lazım olan çox az hal var. Sonra səhv büdcəsi, səhvlər üçün büdcə adlanan şey haqqında danışacağıq. Əslində, belə çıxır ki, hər şey sizin üçün özünüz üçün təyin etdiyiniz SLO-dan daha yaxşıdırsa, bu da çox yaxşı deyil. Bu olduqca pisdir, çünki SLO yalnız aşağı deyil, həm də təxmini yuxarı hədd kimi işləyir. Özünüzə 99% əlçatanlıq SLO təyin etdikdə və əslində 99,99% var, belə çıxır ki, biznesə heç bir zərər verməyəcək təcrübələr üçün bir az yeriniz var, çünki siz özünüz hamısını birlikdə müəyyənləşdirmisiniz və siz bu boşluqdan istifadə etməyin. Səhvlər üçün büdcəniz var, sizin vəziyyətinizdə istifadə olunmur.
Bununla nə edək. Biz sözün əsl mənasında hər şey üçün istifadə edirik. İstehsal şəraitində sınaqdan keçirmək, performansa təsir edə biləcək yeni funksiyaları yaymaq, buraxılışlar, texniki xidmət, planlaşdırılan fasilələr üçün. Əks qayda da tətbiq olunur: əgər büdcə tükənibsə, biz yeni heç nə buraxa bilmərik, çünki əks halda SLO-nu keçəcəyik. Büdcə artıq tükənib, performansa mənfi təsir göstərirsə, yəni bu, birbaşa olaraq SLO-nu artıran bir növ düzəliş deyilsə, biz büdcədən kənara çıxırıq və bu pis vəziyyətdir. , təhlil edilməlidir, postmortem və bəlkə də bəzi proses düzəlişləri.
Yəni belə çıxır ki, xidmətin özü yaxşı işləmirsə və SLO xərclənirsə və büdcə eksperimentlərə deyil, hər hansı buraxılışlara deyil, öz başına xərclənirsə, maraqlı düzəlişlər əvəzinə maraqlı düzəlişlər yerinə maraqlı relizlər əvəzinə xüsusiyyətlər. Hər hansı bir yaradıcı iş görmək əvəzinə, büdcəni qaydasına salmaq və ya SLO-nu redaktə etmək üçün axmaq düzəlişlər etməli olacaqsınız və bu da çox tez-tez baş verməməli olan bir prosesdir.
Buna görə də, səhvlər üçün daha çox büdcəmiz olduğu bir vəziyyətdə hər kəs maraqlanır: həm SRE, həm də tərtibatçılar. Tərtibatçılar üçün səhvlər üçün böyük büdcə onların buraxılışlar, testlər və təcrübələrlə məşğul ola bilməsi deməkdir. SRE-lər üçün səhvlər üçün büdcə və bu büdcəyə daxil olmaq onların həqiqətən yaxşı iş gördükləri deməkdir. Və bu, bir növ birgə işin motivasiyasına təsir göstərir. Tərtibatçılar kimi SRE-lərinizi dinləsəniz, yaxşı iş görmək üçün daha çox yeriniz və daha az işiniz olacaq.
Belə çıxır ki, istehsalda təcrübələr böyük komandalarda SRE-nin kifayət qədər vacib və demək olar ki, ayrılmaz hissəsidir. Və buna adətən xaos mühəndisliyi deyilir, bu da Netflix-də Chaos Monkey adlı yardım proqramını buraxan komandadan gəlir.
Chaos Monkey CI/CD boru kəmərinə qoşulur və istehsalda təsadüfi olaraq serveri qəzaya uğradır. Yenə SRE strukturunda düşürülmüş serverin özlüyündə pis olmamasından, gözlənilməsindən danışırıq. Və büdcə daxilindədirsə, məqbuldur və biznesə zərər vermir. Əlbəttə ki, Netflix-in kifayət qədər lazımsız serverləri, kifayət qədər replikasiyası var ki, bütün bunlar düzəldilə bilsin və bütövlükdə istifadəçi fərqinə varmasın və daha çox heç kim istənilən büdcə üçün bir server buraxmır.
Netflix bir müddət belə kommunalların bütöv dəstinə sahib idi, onlardan biri, Chaos Gorilla, Amazonun Əlçatımlılıq Zonalarından birini tamamilə bağlayır. Və belə şeylər, ilk növbədə, nəyin nəyə təsir etdiyi, nəyin nədən asılı olduğu tam aydın olmayanda, gizli asılılıqları aşkar etməyə kömək edir. Və bu, əgər siz mikroservislə işləyirsinizsə və sənədlər kifayət qədər mükəmməl deyilsə, bu sizə tanış ola bilər. Yenə də, bu, səhnələşdirmə zamanı tuta bilməyəcəyiniz kod səhvlərini tutmağa çox kömək edir, çünki hər hansı bir səhnələşdirmə tam olaraq dəqiq simulyasiya deyil, çünki yük miqyası fərqlidir, yük nümunəsi fərqlidir, avadanlıq fərqlidir. həmçinin, çox güman ki, başqa. Pik yüklər də gözlənilməz və gözlənilməz ola bilər. Və yenə də büdcədən kənara çıxmayan belə sınaq, səhnələşdirmə, avtotestlər, CI / CD boru kəmərinin heç vaxt tuta bilməyəcəyi infrastrukturdakı səhvləri tutmağa çox kömək edir. Və bütün bunlar büdcənizə daxil olduğu müddətcə, xidmətinizin orada aşağı düşməsinin əhəmiyyəti yoxdur, baxmayaraq ki, bu, çox qorxulu görünsə də, server çökdü, nə kabusdu. Xeyr, bu normaldır, bu yaxşıdır, səhvləri tutmağa kömək edir. Büdcəniz varsa, xərcləyə bilərsiniz.
S: Hansı ədəbiyyatı tövsiyə edə bilərəm? Sonda siyahı. Ədəbiyyat çoxdur, bir neçə məruzə ilə bağlı məsləhət verəcəm. Bu necə işləyir və SRE öz proqram məhsulu olmayan və ya minimal inkişafa malik şirkətlərdə işləyir. Məsələn, əsas fəaliyyəti proqram təminatı olmayan müəssisədə. Əsas fəaliyyətinin proqram təminatı olmadığı bir müəssisədə SRE hər yerdə olduğu kimi işləyir, çünki müəssisədə siz də istifadə etməlisiniz, hətta işlənməmiş olsa belə, proqram məhsullarından istifadə etməlisiniz, yeniləmələri yaymalısınız, dəyişdirməlisiniz. infrastruktur, böyümək lazımdır, ölçmək lazımdır. Və SRE-lər bu proseslərdə mümkün problemləri müəyyən etməyə və proqnozlaşdırmağa kömək edir və müəyyən artım başlayandan və biznes ehtiyacları dəyişdikdən sonra onlara nəzarət edir. Çünki ən azı bir neçə serveriniz varsa və ən azı bir qədər böyüməniz gözlənilirsə, SRE-yə sahib olmaq üçün proqram təminatının hazırlanmasında iştirak etmək tamamilə vacib deyil.
Eyni şey kiçik layihələrə, kiçik təşkilatlara da aiddir, çünki böyük şirkətlərin büdcəsi və təcrübə üçün yerləri var. Ancaq eyni zamanda, təcrübələrin bütün bu meyvələrini hər yerdə istifadə etmək olar, yəni SRE, əlbəttə ki, Google-da, Netflix-də, Dropbox-da ortaya çıxdı. Ancaq eyni zamanda, kiçik şirkətlər və startaplar artıq sıxlaşdırılmış materialları oxuya, kitab oxuya, hesabatlara baxa bilərlər. Bu barədə daha tez-tez eşitməyə başlayırlar, konkret misallara baxırlar, məncə, eybi yoxdur, həqiqətən faydalı ola bilər, bizə də bu lazımdır, əladır.
Yəni bu proseslərin standartlaşdırılması üzrə bütün əsas işlər artıq sizin üçün görülüb. Sizə lazım olan tək şey SRE-nin şirkətinizdəki rolunu müəyyən etmək və bütün bu təcrübələri real şəkildə həyata keçirməyə başlamaqdır ki, onlar da artıq təsvir edilmişdir. Yəni kiçik şirkətlər üçün faydalı prinsiplərdən bu, həmişə SLA, SLI, SLO tərifidir. Əgər proqram təminatı ilə məşğul deyilsinizsə, bunlar daxili SLA və daxili SLO, səhvlər üçün daxili büdcə olacaq. Bu, demək olar ki, həmişə komanda daxilində və biznes daxilində maraqlı müzakirələrə səbəb olur, çünki belə çıxa bilər ki, siz infrastruktura, ideal proseslərin bir növ təşkilinə, ideal boru kəmərinə lazım olandan qat-qat artıq pul xərcləyirsiniz. İT departamentində olan bu 4 doqquz, indi onlara ehtiyacınız yoxdur. Ancaq eyni zamanda, vaxt sərf etmək, səhvlərə görə büdcəni başqa bir şeyə xərcləmək mümkün idi.
Müvafiq olaraq, monitorinq və monitorinqin təşkili istənilən ölçülü şirkət üçün faydalıdır. Və ümumiyyətlə, səhvlərin məqbul bir şey olduğu, büdcənin olduğu, Məqsədlərin olduğu bu düşüncə tərzi yenə 3 nəfərlik startaplardan başlayaraq istənilən ölçülü şirkət üçün faydalıdır.
Haqqında danışa biləcəyimiz texniki nüanslardan sonuncusu monitorinqdir. Çünki SLA, SLI, SLO haqqında danışsaq, büdcəyə uyğun olub-olmadığımızı, Məqsədlərimizə uyğun olub-olmadığımızı və yekun SLA-ya necə təsir etdiyimizi izləmədən başa düşə bilmərik. Mən monitorinqin belə baş verdiyini dəfələrlə görmüşəm: server sorğusu vaxtı, orta vaxt və ya verilənlər bazası sorğularının sayı kimi bəzi dəyər var. Onun mühəndis tərəfindən müəyyən edilmiş standartı var. Metrik normadan kənara çıxarsa, e-poçt göndərilir. Bütün bunlar, bir qayda olaraq, tamamilə faydasızdır, çünki bu, xəbərdarlıqların belə həddindən artıq doymasına, monitorinq mesajlarının həddən artıq dolmasına gətirib çıxarır ki, bir şəxs, ilk növbədə, hər dəfə onları şərh etməli, yəni metrik dəyərin ehtiyac olduğunu müəyyən etməlidir. bir növ hərəkət. İkincisi, ondan heç bir hərəkət tələb olunmadığı halda, o, sadəcə olaraq bütün bu xəbərdarlıqları görməyi dayandırır. Yəni, yaxşı monitorinq qaydası və SRE-nin tətbiqi zamanı ilk qayda odur ki, bildiriş yalnız hərəkət tələb olunduqda gəlməlidir.
Standart halda, hadisələrin 3 səviyyəsi var. Xəbərdarlıqlar var, biletlər var, jurnallar var. Xəbərdarlıqlar dərhal tədbir görmənizi tələb edən hər şeydir. Yəni hər şey pozulub, onu dərhal düzəltmək lazımdır. Biletlər gecikmiş hərəkət tələb edən şeylərdir. Bəli, bir şey etmək lazımdır, əl ilə bir şey etmək lazımdır, avtomatlaşdırma uğursuz oldu, ancaq növbəti bir neçə dəqiqə ərzində bunu etmək lazım deyil. Günlüklər hərəkət tələb etməyən hər hansı bir şeydir və ümumiyyətlə, işlər yaxşı gedirsə, heç kim onları oxumayacaq. Yalnız retrospektivdə bir müddət bir şeyin pozulduğu, bu barədə məlumatımız olmadığı ortaya çıxanda qeydləri oxumalısınız. Yoxsa bəzi araşdırmalara ehtiyacınız var. Ancaq ümumiyyətlə, heç bir hərəkət tələb etməyən hər şey loglara gedir.
Bütün bunların bir yan təsiri olaraq, hansı hadisələrin hərəkətlər tələb etdiyini müəyyənləşdirmişiksə və bu hərəkətlərin nə olması lazım olduğunu yaxşı təsvir etmişiksə, bu, hərəkətin avtomatlaşdırıla biləcəyi deməkdir. Yəni nə baş verir. Xəbərdarlıqdan gedirik. Gəlin fəaliyyətə keçək. Bu hərəkətin təsvirinə keçirik. Və sonra avtomatlaşdırmaya keçirik. Yəni istənilən avtomatlaşdırma hadisəyə reaksiya ilə başlayır.
Monitorinqdən biz Müşahidə oluna bilən terminə keçirik. Son bir neçə ildə bu söz ətrafında bir az şırınga da var. Və kontekstdən kənarda bunun nə demək olduğunu az adam başa düşür. Ancaq əsas məqam odur ki, Müşahidə oluna bilənlik sistem şəffaflığı üçün bir metrikdir. Əgər bir şey səhv olarsa, nəyin səhv getdiyini və o anda sistemin nə vəziyyətdə olduğunu nə qədər tez müəyyən edə bilərsiniz. Kod baxımından: hansı funksiya uğursuz oldu, hansı xidmət uğursuz oldu. Vəziyyəti nə idi, məsələn, daxili dəyişənlər, konfiqurasiya. İnfrastruktur baxımından, nasazlığın hansı mövcudluq zonasında baş verdiyi və hər hansı bir Kubernetiniz varsa, hansı podda nasazlıq baş verib, podun vəziyyəti necədir. Müvafiq olaraq, Observability MTTR ilə birbaşa əlaqəyə malikdir. Xidmətin Müşahidə qabiliyyəti nə qədər yüksək olarsa, səhvi müəyyən etmək bir o qədər asan olar, səhvi düzəltmək bir o qədər asan olar, xətanı avtomatlaşdırmaq bir o qədər asan olar, MTTR bir o qədər aşağı olur.
Yenidən kiçik şirkətlərə keçərək, komanda ölçüsü ilə necə məşğul olacağınızı və kiçik bir komandanın ayrıca bir SRE işə götürməsinin lazım olub olmadığını soruşmaq çox yaygındır. Artıq bir az əvvəl bu barədə danışdıq. Bir başlanğıcın və ya məsələn, bir komandanın inkişafının ilk mərhələlərində bu, heç də lazım deyil, çünki SRE keçid rolunu yerinə yetirə bilər. Bu isə komandanı bir az canlandıracaq, çünki ən azı bir qədər müxtəliflik var. Üstəlik bu, insanları böyümə ilə, ümumiyyətlə, SRE-nin vəzifələrinin çox əhəmiyyətli dərəcədə dəyişəcəyinə hazırlayacaqdır. Bir insanı işə götürürsənsə, təbii ki, onun müəyyən gözləntiləri var. Və bu gözləntilər zamanla dəyişməyəcək, lakin tələblər çox dəyişəcək. Buna görə də, SRE-ni necə işə götürmək ilkin mərhələlərdə olduqca çətindir. Özünüzü böyütmək daha asandır. Ancaq bu barədə düşünməyə dəyər.
Yeganə istisna, bəlkə də, çox ciddi və dəqiq müəyyən edilmiş böyümə tələbləri olduqda. Yəni, bir başlanğıc vəziyyətində, bu, investorların bir növ təzyiqi, bir növ artım üçün bir neçə dəfə bir proqnoz ola bilər. Sonra bir SRE-nin işə götürülməsi əsasən əsaslandırılır, çünki bu, əsaslandırıla bilər. Bizim böyümə üçün tələblərimiz var, bizə belə bir böyümə ilə heç bir şeyin pozulmayacağına görə məsuliyyət daşıyacaq bir insan lazımdır.
Daha bir sual. Tərtibatçılar bir neçə dəfə testlərdən keçən, lakin məhsulu pozan, verilənlər bazasını yükləyən, digər xüsusiyyətləri pozan, hansı prosesi həyata keçirən funksiyanı kəsdikdə nə etməli. Müvafiq olaraq, bu halda səhvlər üçün büdcə təqdim edilir. Bəzi xidmətlər, bəzi xüsusiyyətlər dərhal istehsalda sınaqdan keçirilir. Bu, yalnız az sayda istifadəçinin, lakin artıq istehsalda olan bir xüsusiyyəti tətbiq etdiyi zaman, lakin bir şey pozulduğu təqdirdə, məsələn, bütün istifadəçilərin yarısı üçün, o, hələ də proqram daxilində uyğunlaşacağı gözlənilən bir kanarya ola bilər. səhvlər üçün büdcə. Müvafiq olaraq, bəli, bir səhv olacaq, bəzi istifadəçilər üçün hər şey pozulacaq, lakin bunun normal olduğunu artıq söylədik.
SRE alətləri ilə bağlı bir sual var idi. Yəni, SRE-lərin istifadə edəcəyi, başqalarının istifadə etmədiyi xüsusi bir şey varmı? Əslində, bəzi yüksək ixtisaslaşmış kommunal proqramlar var, məsələn, yükləri simulyasiya edən və ya kanarya A / B testi ilə məşğul olan bir növ proqram var. Lakin əsasən SRE alət dəsti sizin tərtibatçılarınızın artıq istifadə etdiyi şeydir. Çünki SRE birbaşa inkişaf komandası ilə qarşılıqlı əlaqədədir. Fərqli alətləriniz varsa, sinxronizasiya üçün vaxt lazım olduğu ortaya çıxacaq. Xüsusən də SRE-lər böyük komandalarda, bir neçə komandanın ola biləcəyi böyük şirkətlərdə işləyirsə, burada çox kömək edəcək şirkət miqyasında standartlaşdırmadır, çünki 50 komandada 50 müxtəlif kommunal xidmətlərdən istifadə olunursa, bu o deməkdir ki, SRE onları bilməlidir. hamısı. Və təbii ki, bu heç vaxt baş verməyəcək. Və işin keyfiyyəti, ən azı bəzi komandaların nəzarət keyfiyyəti xeyli aşağı düşəcək.
Vebinarımız sona yaxınlaşır. Bəzi əsas şeyləri söyləməyi bacardım. Təbii ki, bir saat ərzində SRE haqqında heç nə demək və başa düşmək olmaz. Amma ümid edirəm ki, bu düşüncə tərzini, əsas əsas məqamları çatdıra bildim. Və sonra, əgər maraqlanırsınızsa, mövzunu araşdırmaq, özünüz öyrənmək, başqa insanlar tərəfindən, başqa şirkətlərdə necə həyata keçirildiyinə baxmaq mümkün olacaq. Və müvafiq olaraq, fevralın əvvəlində Slurm SRE-də bizə gəlin.
Slurm SRE üç günlük intensiv kursdur, indi danışdığım şeylər haqqında danışacaq, lakin daha dərindən, real hadisələrlə, təcrübə ilə, bütün intensiv praktiki işə yönəlib. İnsanlar komandalara bölünəcək. Hamınız real işlər üzərində işləyəcəksiniz. Müvafiq olaraq, Booking.com təlimatçılarımız İvan Kruqlov və Ben Tayler var. Google-dan, San-Fransiskodan gözəl Eugene Barabbas var. Mən də sizə bir şey deyim. Odur ki, bizi ziyarət etməyinizə əmin olun.
Beləliklə, biblioqrafiya. SRE ilə bağlı istinadlar var. eyni kitabda, daha doğrusu Google tərəfindən yazılmış SRE haqqında 2 kitabda. Başqa biri , burada şərtlər və onların tətbiqi bir az daha ətraflıdır. Növbəti 3-ü müxtəlif şirkətlərdə SRE ilə bağlı hesabatlardır. Birinci - , bu, Google-dan Ben Təlimçinin əsas çıxışıdır. İkinci - . Üçüncüsü yenə haqqındadır . Dördüncü hesabat 5 ölkədə yalnız 190 əsas SRE əməkdaşı olan . Bütün bunlara baxmaq çox maraqlıdır, çünki DevOps müxtəlif şirkətlər və hətta fərqli komandalar üçün çox fərqli şeylər ifadə etdiyi kimi, SRE-nin də, hətta oxşar ölçülü şirkətlərdə də çox fərqli məsuliyyətləri var.
Xaos mühəndisliyi prinsipləri haqqında daha 2 keçid: , . Və sonunda haqqında Awesome Lists seriyasından 3 siyahı var , haqqında və haqqında . SRE-dəki siyahı inanılmaz dərəcədə böyükdür, hamısını nəzərdən keçirmək lazım deyil, 200-ə yaxın məqalə var. Mən oradan potensialın planlaşdırılması və günahsız postmortem haqqında məqalələri tövsiyə edirəm.
Maraqlı məqalə:
Bütün bu müddət ərzində məni dinlədiyiniz üçün təşəkkür edirəm. Ümid edirəm bir şey öyrənmisiniz. Ümid edirəm ki, daha çox öyrənmək üçün kifayət qədər materialınız var. Və görüşərik. İnşallah fevralda.
Vebinar Eduard Medvedev tərəfindən aparılıb.
PS: oxumağı sevənlər üçün Eduard istinadlar siyahısını verdi. Praktikada başa düşməyə üstünlük verənlər dəvətlidir .
Mənbə: www.habr.com