У вебинара дрэнны гук, таму мы зрабілі расшыфроўку.
Мяне клічуць Мядзведзеў Эдуард. Я сёння пагавару аб тым, што такое SRE, як з'явілася SRE, якія ёсць крытэрыі працы ў SRE-інжынераў, трошкі аб крытэрах надзейнасці, трошкі аб яе маніторынгу. Мы пройдземся па вярхах, таму што за гадзіну шмат не раскажаш, але я дам матэрыялы для дадатковага азнаямлення, і мы ўсе чакаем вас на . у Маскве ў канцы студзеня.
Спачатку пагаворым аб тым, што наогул такое SRE – Site Reliability Engineering. І як яно з'явілася як асобная пасада, як асобны напрамак. Усё пачалося з таго, што ў традыцыйных колах распрацоўкі Dev і Ops - гэта дзве зусім розныя каманды, як правіла, з двума зусім рознымі мэтамі. Мэта каманды распрацоўкі - выкочваць новыя фічы, адказваць патрэбам бізнесу. Мэта каманды Ops у тым, каб усё працавала і нічога не ламалася. Відавочна, гэтыя мэты наўпрост адзін аднаму супярэчаць: каб усё працавала і нічога не ламалася выкочваць новых фіч лепш як мага менш. З-за гэтага ўзнікае шмат унутраных канфліктаў, якія спрабуе вырашыць метадалогія, якая зараз называецца DevOps.
Праблема ў тым, што дакладнага вызначэння DevOps і дакладнай імплементацыі DevOps у нас няма. Я выступаў на канферэнцыі ў Екацярынбурзе 2 гады таму, і да гэтага часу секцыя DevOps пачыналася дакладам "Што такое DevOps". У 2017 годзе дэвапсу ўжо практычна 10 гадоў, але мы да гэтага часу спрачаемся, што ж гэта такое. І гэта вельмі дзіўная сітуацыя, якую паспрабаваў вырашыць Google некалькі гадоў таму.
У 2016 годзе Google выпусціў кнігу, якая называецца "Site Reliability Engineering". І па факце менавіта з гэтай кнігі пачаўся рух SRE. SRE - гэта канкрэтны варыянт імплементацыі DevOps парадыгмы ў канкрэтнай кампаніі. Інжынеры SRE ставяць сабе мэту забяспечыць надзейную працу сістэм. У асноўным яны бяруцца з распрацоўшчыкаў, часам з адміністратараў з моцным бэкграўндам распрацоўкі. І займаюцца тым, чым раней займаліся сістэмныя адміністратары, але моцны бэкграўнд у распрацоўцы і веданне сістэмы з пункту гледжання кода вядуць да таго, што гэтыя людзі не схільныя да руціннай адміністратарскай працы, а схільныя да аўтаматызацыі.
Атрымліваецца так, што DevOps парадыгма ў SRE-камандах імплементуецца тым, што ёсць SRE-інжынеры, якія вырашаюць структурныя праблемы. Вось яна, тая самая сувязь Dev і Ops, пра якую людзі ўжо 8 гадоў гавораць. Роля SRE падобная на ролю архітэктара ў тым плане, што навічкі SRE не становяцца. Людзі ў пачатку кар'еры яшчэ не маюць нейкага досведу, не маюць патрэбнай шыраты ведаў. Таму што SRE патрабуе вельмі тонкіх ведаў, што менавіта і калі менавіта можа пайсці не так. Таму тут патрэбен нейкі досвед, як правіла, і ўсярэдзіне кампаній, і звонку.
Пытаюцца, ці будзе апісана розніца паміж SRE і дэвопс. Яна толькі што была апісана. Можам пагаварыць аб месцы SRE у арганізацыі. У адрозненне ад такога класічнага падыходу DevOps, дзе Ops - гэта ўсё-такі адасоблены аддзел, SRE - гэта частка каманды распрацоўкі. Яны ўдзельнічаюць у распрацоўцы прадукта. Ёсць нават падыход, дзе SRE - гэта роля, якая пераходзіць ад аднаго распрацоўніка да іншага. Яны ўдзельнічаюць у рэўю кода сапраўды таксама, як, напрыклад, UX-дызайнеры, самі распрацоўнікі, часам прадуктовыя мэнэджары. На гэтым жа ўзроўні працуюць SRE. Патрэбен іх аппруў, трэба іх рэўю, каб на кожны дэплой SRE сказаў: «Добра, гэты дэплой, гэты прадукт не паўплывае адмоўна на надзейнасць. А калі паўплывае, то ў нейкіх дапушчальных межах». Аб гэтым мы таксама пагаворым.
Адпаведна ў SRE ёсць вета на змену кода. І ў цэлым гэта таксама прыводзіць да нейкага невялікага канфлікту, калі SRE рэалізавана няправільна. У той самай кнізе пра Site Reliability Engineering шмат частак, нават не адна, расказваюць, як гэтых канфліктаў пазбегнуць.
Пытаюцца, якім чынам SRE суадносіцца з інфармацыйнай бяспекай. SRE напрамую не займаецца інфармацыйнай бяспекай. У асноўным у вялікіх кампаніях гэтым займаюцца асобныя людзі, тэсціроўшчыкі, аналітыкі. Але SRE сапраўды таксама ўзаемадзейнічае з імі ў тым плане, што нейкія аперацыі, нейкія коміты, нейкія дэплоі, якія закранаюць бяспеку, таксама могуць паўплываць на даступнасць прадукта. Таму ў SRE у цэлым ёсць узаемадзеянне з любымі камандамі, у тым ліку з камандамі бяспекі, у тым ліку з аналітыкамі. Таму ў асноўным SRE патрэбныя, калі спрабуюць укараніць DevOps, але пры гэтым нагрузка на распрацоўшчыкаў становіцца занадта вялікай. Гэта значыць, сама каманда распрацоўкі ўжо не спраўляецца з тым, што зараз ім трэба адказваць яшчэ і за Ops. І з'яўляецца асобная роля. Гэта роля плануецца ў бюджэце. Часам гэтая роля закладваецца ў памер каманды, з'яўляецца асобны чалавек, часам ёй становіцца нехта з распрацоўшчыкаў. Так, у камандзе з'яўляецца першы SRE.
Складанасць сістэмы, на якую ўплывае SRE, складанасць, якая ўплывае на надзейнасць працы, бывае неабходнай і выпадковай. Неабходная складанасць гэта калі складанасць прадукта павялічваецца ў тым аб'ёме, якога патрабуюць новыя прадуктовыя фічы. Выпадковая складанасць гэта калі складанасць сістэмы падвышаецца, але прадуктовая фіча і патрабаванні бізнэсу напроста на гэта не ўплываюць. Атрымліваецца, што або распрацоўшчык дапусціў дзесьці памылку, або алгарытм не аптымальны, або ўводзяцца нейкія дадатковыя інтарэсы, якія павышаюць складанасць прадукта без асаблівай неабходнасці. Добры SRE гэтую сітуацыю заўсёды павінен адсякаць. Гэта значыць, любы коміт, любы дэплой, любы pull-рэквест, дзе павялічваецца складанасць за рахунак выпадковага дадатку, павінен блакавацца.
Пытанне, чаму проста не наняць у каманду інжынера, сістэмнага адміністратара з вялікім багажом ведаў. Распрацоўнік у ролі інжынера, кажуць нам, не самае аптымальнае кадравае рашэнне. Распрацоўнік у ролі інжынера не заўсёды аптымальнае кадравае рашэнне, але гаворка тут аб тым, што распрацоўшчык, які займаецца Ops, мае крыху больш імкнення да аўтаматызацыі, мае крыху большы багаж ведаў і скілсэт для таго, каб гэтую аўтаматызацыю ўкараняць. І адпаведна мы памяншаем не толькі час на нейкія пэўныя аперацыі, не толькі руціну, але і такія важныя для бізнэсу параметры, як MTTR (Mean Time To Recovery, час аднаўлення). Такім чынам, і пра гэта таксама будзе крыху пазней, мы эканомім для арганізацыі грошы.
Зараз пагаворым аб крытэрах працы SRE. І ў першую чаргу аб надзейнасці. У невялікіх кампаніях, стартапа вельмі часта атрымліваецца так, што людзі мяркуюць, калі сэрвіс напісаны добра, калі прадукт напісаны добра і правільна, ён будзе працаваць, ён не зламаецца. Усё, мы пішам добры код, таму ламацца няма чаму. Код вельмі просты, ламацца няма чаму. Гэта прыкладна тыя ж людзі, якія кажуць, што тэсты нам не патрэбныя, таму што, гледзіце, гэта ж тры метаду VPI, чаму тут ламацца.
Гэта ўсё зразумела няправільна. І гэтых людзей вельмі часта такі код вельмі кусае на практыцы, бо рэчы ламаюцца. Рэчы ламаюцца часам самымі непрадказальнымі спосабамі. Часам людзі гавораць, што не, гэтага ніколі не здарыцца. А яно ўсё роўна здараецца. Бывае дастаткова часта. І таму ніхто ніколі не імкнецца да 100% даступнасці, бо 100% даступнасці не бывае ніколі. Гэта норма. І таму мы заўсёды, калі які гаворыцца аб даступнасці сэрвісу, які гаворыцца аб дзявятках. 2 дзявяткі, 3 дзявяткі, 4 дзявяткі, 5 дзявятак. Калі пераводзіць гэта на час даунтайма, то, напрыклад, 5 дзявятак, то гэта крыху больш за 5 хвілін даунтайма ў год, 2 дзявяткі гэта 3,5 дня даунтаймаў.
Але відавочна, што ў нейкі момант адбываецца памяншэнне POI, аддачы інвестыцый. Перайсці з двух дзявятак на тры дзявяткі, гэта азначае паменшыць даунтайм на 3 з лішнім дня. Пераход з чатырох дзявятак да пяці памяншае даунтайм на 47 хвілін у год. І атрымліваецца так, што для бізнэсу гэта можа быць не крытычна. І ў цэлым патрабаваная надзейнасць гэта пытанне не тэхнічнае, у першую чаргу, гэта пытанне бізнэсу, гэта пытанне прадукта. Які ўзровень даунтайма дапусцім для карыстальнікаў прадукта, чаго яны чакаюць, колькі яны плацяць, напрыклад, колькі грошай яны губляюць, колькі грошай губляе сістэма.
Важнае пытанне пры гэтым, якая надзейнасць астатніх кампанентаў. Таму што розніца паміж 4 і 5 дзявяткамі не будзе бачная на смартфоне з 2 дзявяткамі надзейнасці. Грубіянска кажучы, калі ў год нешта ламаецца на смартфоне ў вашым сэрвісе 10 раз, хутчэй за ўсё 8 раз паломка адбылася менавіта на боку АС. Карыстальнік да гэтага абвык, і на адзін лішні раз у год не зверне ўвагі. Трэба суадносіць кошт павышэння надзейнасці і павелічэння прыбытку.
Як раз у кнізе па SRE ёсць добры прыклад павелічэння да 4 дзявятак з 3 дзявятак. Атрымліваецца, што прырост даступнасці гэта крыху менш за 0,1%. І калі выручка сэрвісу складае 1 млн долараў за год, то прырост выручкі 900 долараў. Калі павышэнне даступнасці на дзявятку абыдзецца нам менш, чым у 900 долараў за год, гэты прырост мае фінансавы сэнс. Калі ён каштуе больш за 900 долараў за год, сэнсу ён ужо не мае, таму што прырост выручкі проста не кампенсуе працазатраты, рэсурсазатраты. І 3 дзявятак нам будзе цалкам дастаткова.
Гэта, вядома, спрошчаны прыклад, дзе ўсе запыты роўныя. І з 3 дзявятак да 4 дзявятак перайсці дастаткова проста, але пры гэтым, напрыклад, перайсці з 2 дзявятак да 3, гэта ўжо эканомія ў 9 тысяч долараў, яна можа мець фінансавы сэнс. Натуральна ў рэальнасці правал запыту на рэгістрацыю горш за правал на адлюстраванне старонкі, запыты маюць розную вагу. У іх можа быць зусім розны крытэр з пункту гледжання бізнесу, але ўсё роўна, як правіла, калі мы не гаворым пра нейкія спецыфічныя сэрвісы, гэта дастаткова надзейная апраксімацыя.
Атрымалі пытанне, ці з'яўляецца SRE адным з узгадняючых пры выбары архітэктурнага рашэння сэрвісу. Дапусцім у плане інтэграцыі ў існуючую інфраструктуру, каб не было страт у яе стабільнасці. Так, SRE сапраўды таксама, як уплываюць на pull-рэквесты, коміты, рэлізы, яны ўплываюць на архітэктуру, на ўкараненне новых сэрвісаў, мікрасэрвісаў, на ўкараненне новых рашэнняў. Чаму я да гэтага казаў, што патрэбен досвед, патрэбная кваліфікацыя. Па сутнасці SRE гэта адзін з блакіруючых галасоў у любым архітэктурным і праграмным рашэнні. Адпаведна SRE як інжынер павінен, у першую чаргу, не проста разбірацца, але і разумець, як нейкія канкрэтныя рашэнні паўплываюць на надзейнасць, на стабільнасць, і разумець, як гэта суадносіцца з бізнэс-патрэбамі, і з якога пункта гледжання гэта можа быць. дапушчальна, а з якой не.
Таму зараз як раз можна пагаварыць аб крытэрах надзейнасці, якія ў SRE традыцыйна вызначаюцца як SLA (Service Level Agreement). Хутчэй за ўсё, знаёмы тэрмін. SLI (Service Level Indicator). SLO (Service Level Objective). Service Level Agreement магчыма знакавы тэрмін, асабліва калі вы працавалі з сеткамі, з правайдэрамі, з хостынгам. Гэта агульная дамова, якая апісвае працаздольнасць усяго вашага сэрвісу, пенальці, нейкія штрафы за памылкі, метрыкі, крытэры. А SLI - гэта сама метрыка даступнасці. Гэта значыць, што можа быць SLI: час адказу ад сэрвісу, колькасць памылак у працэнтных суадносінах. Гэта можа быць прапускная здольнасць, калі гаворка ідзе пра нейкі файлавы хостынг. Калі гаворка ідзе пра алгарытмы распазнання, індыкатарам можа быць, напрыклад, нават карэктнасць адказу. SLO (Service Level Objective) - гэта адпаведна спалучэнне індыкатара SLI, яго значэння і перыяду.
Дапушчальны, SLA можа быць такі. Сэрвіс даступны 99,95 працэнта часу на працягу года. Або 99 крытычных тыкетаў тэхпадтрымкі будзе зачынена на працягу 3-х гадзін за квартал. Або 85% запытаў атрымаюць адказы на працягу 1,5 секунды кожны месяц. Гэта значыць, мы паступова прыходзім да разумення таго, што памылкі і збоі - гэта цалкам нармальна. Гэта дапушчальная сітуацыя, мы яе плануем, мы на яе ў нейкай меры нават разлічваем. Гэта значыць, SRE будуе сістэмы, якія могуць памыляцца, якія павінны нармальна рэагаваць на памылкі, якія павінны іх улічваць. І па магчымасці яны павінны апрацоўваць памылкі такім чынам, што карыстач альбо не заўважае іх, альбо заўважае, але ёсць нейкі абыходны шлях, дзякуючы якому ўсё не зваліцца спрэс.
Напрыклад, калі заліваць відэа на ютуб, і ютуб не можа канвертаваць яго адразу, калі відэа занадта вялікае, калі фармат не аптымальны, то запыт натуральна не зваліцца з тайм-аўтам, ютуб не выдасць памылку 502, ютуб скажа: «Мы ўсё стварылі, ваша відэа апрацоўваецца. Яно будзе гатова прыкладна праз 10 хвілін». Гэта прынцып graceful degradation, які знаёмы, напрыклад, па распрацоўцы фронтэнда, калі вы калісьці гэтым займаліся.
Наступныя тэрміны, пра якія мы будзем казаць, якія вельмі важныя для працы з надзейнасцю, з памылкамі, з чаканнямі, гэта MTBF і MTTR. MTBF - гэта сярэдні час паміж збоямі, mean time between failures. MTTR Mean Time To Recovery, сярэдні час да аднаўлення. Гэта значыць, колькі часу прайшло ад моманту выяўлення памылкі, ад моманту з'яўлення памылкі да моманту аднаўлення поўнасцю нармальнай працы сэрвісу. MTBF у асноўным выпраўляецца працай над якасцю кода. Гэта значыць, тым, што SRE могуць сказаць "не". І трэба разуменне ўсёй каманды, што калі SRE кажа "не", ён кажа гэта не таму што ён шкодны, не таму што ён дрэнны, а таму што інакш усе будуць пакутаваць.
Ізноў жа, ёсць вельмі шмат артыкулаў, вельмі шмат метадаў, вельмі шмат спосабаў нават у той самай кнізе, на якую я так часта спасылаюся, як жа зрабіць, каб астатнія распрацоўнікі не пачалі ненавідзець SRE. MTTR, з іншага боку, гэта праца над вашымі SLO (Service Level Objective). І гэта збольшага аўтаматызацыя. Таму што, напрыклад, наш SLO гэта аптайм 4 дзявяткі на квартал. Значыць, што за 3 месяцы мы можам дапусціць 13 хвілін даунтайму. І атрымліваецца, што MTTR у нас ніяк не можа быць больш за 13 хвілін. Калі мы будзем 13 хвілін рэагаваць хаця б на 1 даунтайм, гэта азначае, што ўвесь бюджэт на квартал мы ўжо вычарпалі. Мы SLO парушаем. 13 хвілін на рэакцыю і выпраўленне збою - гэта вельмі шмат для машыны, але вельмі мала для чалавека. Бо пакуль чалавеку прыйдзе алерт, пакуль ён зрэагуе, пакуль ён разбярэцца ў памылцы, гэта ўжо некалькі хвілін. Пакуль чалавек зразумее, як яе выправіць, што менавіта паправіць, што зрабіць, то гэта яшчэ некалькі хвілін. І па сутнасці нават калі проста трэба перазагрузіць сервер, як аказваецца, або падняць новую ноду, то MTTR уручную гэта ўжо прыкладна 7-8 хвілін. Пры аўтаматызацыі працэсу MTTR вельмі часта дасягае секунды, часам мілісекунд. Google кажа аб мілісекундах звычайна, але ў рэальнасці ўсё вядома ідзе не так добра.
У ідэале SRE павінен практычна цалкам аўтаматызаваць сваю працу, таму што гэта наўпрост уплывае на MTTR, на яго метрыкі, на SLO за ўсё сэрвісу, і адпаведна на прыбытак бізнэсу. Калі перавышаны час, пытаюцца нас, ці ўскладаецца віна на SRE. Па добраму, віна не ўскладаецца ні на каго. І гэта асобная культура, якая называецца balmeless postmortem, пра якую мы сёння не пагаворым, але будзем разбіраць на Слёрме. Гэта вельмі цікавая тэма, пра якую можна шмат казаць. Грубіянска кажучы, калі перавышана адведзены час у квартал, то вінаватыя патроху ўсё, а гэта значыць, што вінаваціць усіх не прадуктыўна, давайце замест гэтага, можа быць, не вінаваціць нікога, а выпраўляць сітуацыю і працаваць з тым, што мы маем. На маю вопыту, такі падыход большасці каманд, асабліва ў Расіі, крыху чужы, але ён мае сэнс і працуе вельмі добра. Таму я парэкамендую ў канцы артыкула і літаратуру, якія можна на гэтую тэму пачытаць. Або прыходзьце на Слёрм SRE.
Растлумачу. Калі перавышаны час SLO у квартал, калі даунтайма было не 13 хвілін, а 15, хто ў гэтым можа быць вінаваты? Вядома, можа быць вінаваты SRE, таму што ён відавочна дапусціў нейкі дрэнны коміт ці дэплой. У гэтым можа быць вінаваты адміністратар дата-цэнтра, бо правёў, магчыма, нейкі пазапланавы maintenance. Калі ў гэтым вінаваты адміністратар дата-цэнтра, адпаведна ў гэтым вінаваты чалавек з Ops, які не разлічыў maintenance, калі ўзгадняў SLO. У гэтым вінаваты мэнэджар, тэхнічны дырэктар ці хтосьці, хто падпісваў дамову дата-цэнтра і не звярнуў увагу, што SLA дата цэнтра не разлічаны на патрэбны даунтайм. Адпаведна ўсё пакрысе ў гэтай сітуацыі вінаватыя. І значыць, ні на кога асабліва няма сэнсу ўскладаць віну ў гэтай сітуацыі. Але выправіць яе, вядома, трэба. Таму існуюць постмартэмы. І калі пачытаць, напрыклад, постмартэмы Гітхаба, а гэта заўсёды вельмі цікавая, маленькая і нечаканая гісторыя ў кожным канкрэтным выпадку, можна замяніць, што там ніхто ніколі не кажа, што аказаўся вінаваты гэты канкрэтны чалавек. Віна заўсёды ўскладаецца на канкрэтныя недасканалыя працэсы.
Пяройдзем да наступнага пытання. Аўтаматызацыя. Я звычайна, калі кажу пра аўтаматызацыі ў іншых кантэкстах, вельмі часта спасылаюся на табліцу, якая расказвае пра тое, наколькі доўга можна працаваць над аўтаматызацыяй задачы, каб не заняць на яе аўтаматызацыю больш часу, чым вы наогул эканоміце. Ёсць загваздка. Загваздка ў тым, што калі SRE аўтаматызуюць нейкую задачу, яны эканомяць не толькі час, яны эканомяць грошы, таму што аўтаматызацыя напрамую ўплывае на MTTR. Яны эканомяць, калі можна так сказаць, мараль супрацоўнікаў і распрацоўшчыкаў, якая таксама вычарпаны рэсурс. Яны памяншаюць руціну. І гэта ўсё станоўча адбіваецца на працы і як следства на бізнэсе, нават калі здаецца, што аўтаматызацыя не мае сэнсу з пункту гледжання часавых затрат.
Па факце амаль заўсёды мае, і ёсць вельмі мала выпадкаў, калі ў ролі SRE нешта аўтаматызаваць не варта. Далей мы пагаворым аб тым, што завецца error budget, бюджэт на памылкі. Па факце выходзіць так, што калі ў вас усё значна лепш, чым SLO, які вы паставілі сабе, гэта таксама ня вельмі добра. Гэта хутчэй дрэнна, таму што SLO працуе не толькі як ніжняя, але і як прыкладная верхняя мяжа. Калі вы паставілі сабе SLO у 99% даступнасці, а ў вас па факце 99,99%, атрымліваецца, што ў вас ёсць нейкая прастора для эксперыментаў, якая зусім не пашкодзіць бізнэсу, таму што вы самі ўсё разам гэта вызначылі, і вы гэтая прастора не карыстаецеся. У вас ёсць бюджэт на памылкі, якія ў вашым выпадку не зрасходаваны.
Што мы з ім робім. Мы выкарыстоўваем яго літаральна на ўсё. На тэставанне ва ўмовах прадакшэна, на выкатку новых фіч, якія могуць паўплываць на прадукцыйнасць, на рэлізы, на maintenance, на планавыя даунтаймы. Адваротнае правіла таксама дзейнічае: калі бюджэт вычарпаны, мы не можам зарэлізаваць нічога новага, таму што ў нас інакш перавысіцца SLO. Бюджэт ужо вычарпаны, мы нешта зарэлізавалі, калі яно паўплывае негатыўна на прадукцыйнасць, гэта значыць, калі гэта не нейкі фікс, які сам па сабе наўпрост павышае SLO, то мы выходзім за бюджэт, а гэта дрэнная сітуацыя, яна патрабуе разбору. , постмартэма, і магчыма нейкага выпраўлення працэсаў.
Гэта значыць, атрымліваецца, што калі сэрвіс сам па сабе працуе дрэнна, і SLO расходуецца і бюджэт расходуецца на не эксперыменты, не на нейкія рэлізы, а сам сабой, то распрацоўнікам замест цікавых нейкіх фіксаў, замест цікавых фіч, замест цікавых рэлізаў. Замест нейкай любой творчай працы давядзецца займацца тупымі фіксамі, каб вярнуць бюджэт у парадак, альбо адрэдагаваць SLO, а гэта таксама працэс, які не павінен занадта часта адбывацца.
Таму атрымліваецца, што ў сітуацыі, дзе ў нас застаецца больш за бюджэт на памылкі, зацікаўлены ўсе: і SRE, і распрацоўшчыкі. Для распрацоўшчыкаў вялікі бюджэт на памылкі значыць, што можна займацца рэлізамі, тэстамі, эксперыментамі. Для SRE бюджэт на памылкі і ўваход у гэты бюджэт азначае, што яны ўласна напрамую добра робяць сваю працу. І гэта ўплывае на матывацыю нейкай сумеснай працы. Калі вы будзеце слухаць вашых SRE як распрацоўшчыкі, у вас будзе больш прасторы на добрую працу і значна менш руціны.
Атрымліваецца так, што эксперыменты ў прадакшэне гэта дастаткова важная і амаль неад'емная частка SRE у вялікіх камандах. І яна як правіла носіць назву chaos ingeneering, якая пайшла ад каманды ў Нетфлікс, якая выпусціла ўтыліту, якая называецца Chaos Monkey.
Chaos Monkey падлучаецца да CI/CD пайплайну і выпадковым чынам губляе ў прадакшэне сервер. Ізноў жа, у SRE структуры мы кажам аб тым, што які ўпаў сервер – гэта само па сабе не дрэнна, гэта чакана. І калі гэта ўваходзіць у бюджэт, гэта дапушчальна і не шкодзіць бізнэсу. Зразумела, у Нетфлікса ёсць дастаткова дублюючых сервераў, дастаткова рэплікацыі, каб гэта ўсё можна было выправіць, і каб карыстач у цэлым нават не заўважыў, і ўжо тым больш ніхто не выйшаў ад аднаго сервера ні за які бюджэт.
У Нетфлікса ў нейкі час быў цэлы набор такіх утыліт, адна з якіх, Chaos Gorilla, выключае цалкам адну з зон даступнасці ў Амазоне. І падобныя рэчы добра дапамагаюць выявіць, па-першае, утоеныя залежнасці, калі не зусім зразумела, што на што ўплывае, што ад чаго залежыць. А гэта, калі вы працуеце з мікрасэрвісам, і дакументацыя не зусім ідэальная, гэта можа быць вам знаёма. І зноў жа гэта добра дапамагае вылоўліваць памылкі ў кодзе, якія вы не можаце злавіць на стэйджынгу, таму што любы стэйджынг гэта ўсё роўна не дакладная сімуляцыя, з-за таго, што іншы маштаб нагрузак, іншы патэрн нагрузак, абсталяванне таксама, хутчэй за ўсё, іншае. Пікавыя нагрузкі таксама могуць быць нечаканымі і непрадказальнымі. І такое тэсціраванне, якое зноў жа не выходзіць за рамкі бюджэту, вельмі добра дапамагае адлавіць памылкі ў інфраструктуры, якія стэйджынг, аўтатэсты, CI/CD пайплайн ніколі не выловяць. І пакуль гэта ўсё ўваходзіць у ваш бюджэт, не мае ніякага значэння, што ў вас там упаў сэрвіс, хаця, здавалася б, вельмі страшна, упаў сервер, які кашмар. Не, гэта нармальна, гэта добра, гэта дапамагае лавіць памылкі. Ёсць бюджэт, значыць можна яго марнаваць.
Пытанне: якую літаратуру я магу параіць? Спіс у канцы. Літаратуры вельмі шмат, параю некалькі дакладаў. Як працуе, і ці працуе SRE у кампаніях без свайго праграмнага прадукта або з мінімальнай распрацоўкай. Напрыклад, у энтэрпрайзе, дзе асноўная дзейнасць не ПЗ. У энтерпрайзе, дзе асноўная дзейнасць не ПА, SRE працуе сапраўды таксама як і ўсюды, таму што ў энтерпрайзе сапраўды таксама трэба выкарыстоўваць, нават калі не распрацоўваць, праграмныя прадукты, трэба выкочваць апдэйты, трэба змяняць інфраструктуру, трэба расці, трэба скейлі. І SRE дапамагаюць вызначыць і прадказаць магчымыя праблемы ў гэтых працэсах і пракантраляваць іх ужо пасля таго, як пачнецца нейкі рост і запатрабаванні бізнэсу памяняюцца. Таму што зусім не абавязкова займацца распрацоўкай ПЗ для таго, каб было SRE, калі ў вас ёсць хаця б некалькі сервераў і ў вас чакаецца хаця б нейкі рост.
Тое ж тычыцца невялікіх праектаў, невялікіх арганізацый, таму што ў вялікіх кампаній ёсць бюджэт і прастора для эксперыментаў. Але пры гэтым усімі гэтымі пладамі эксперыментаў можна карыстацца дзе заўгодна, гэта значыць SRE вядома з'явіліся ў Google, у Нетфлікс, у Дропбоксе. Але пры гэтым невялікія кампаніі і стартапы ўжо могуць пачытаць кандэнсаваны матэрыял, пачытаць кнігі, паглядзець даклады. Яны пачынаюць чуць пра гэта часцей, глядзяць на канкрэтныя прыклады, думаю, гэта акей, гэта сапраўды можа быць карысна, нам таксама такое патрэбна, класна.
Гэта значыць, усю асноўную працу па стандартызацыі гэтых працэсаў за вас ужо прарабілі. Вам засталося вызначыць ролю SRE канкрэтна ў вашай кампаніі і пачаць уласна ўкараняць усе гэтыя практыкі, якія зноў жа ўжо апісаны. Гэта значыць, з карысных прынцыпаў для невялікіх кампаній, гэтае заўсёды вызначэнне SLA, SLI, SLO. Калі вы не займаецеся ПЗ, то гэта будуць унутраныя SLA і ўнутраныя SLO, унутраны бюджэт на памылкі. Гэта заўсёды практычна прыводзіць да нейкіх цікавых дыскусій усярэдзіне каманды і ўсярэдзіне бізнэсу, таму што магчыма апынецца, што вы марнуеце на інфраструктуру, на нейкую арганізацыю ідэальных працэсаў, ідэальнага пайплайна значна больш, чым трэба. І гэтыя 4 дзявяткі, якія ў вас ёсць у IT аддзеле, яны вам зараз не вельмі патрэбныя. Але пры гэтым можна было патраціць час, патраціць бюджэт на памылкі на што-небудзь яшчэ.
Адпаведна маніторынг і арганізацыя маніторынгу карысная для кампаніі любога памеру. І ў цэлым вось гэта выява думкі, дзе памылкі гэта штосьці дапушчальнае, дзе існуе бюджэт, дзе існуюць Objectives, ён ізноў жа карысны для кампаніі любога памеру, пачынальна ад стартапаў на 3 чалавека.
Апошняе з тэхнічных нюансаў, пра што можна паразмаўляць, гэта маніторынг. Таму што калі мы гаворым пра SLA, SLI, SLO, мы ніяк не можам без маніторынгу зразумець, ці ўпісваемся мы ў бюджэт, ці выконваем мы нашы Objectives, і як мы ўплываем на фінальны SLA. Я вельмі шмат разоў назіраў, што маніторынг адбываецца наступным чынам: ёсць нейкае значэнне, напрыклад час запыту да сервера, сярэдні час ці колькасць запытаў да базы дадзеных. У яго ёсць вызначаная інжынерам норма. Калі метрыка адхіляецца ад нормы, тое прылятае е-мэйл. Гэта ўсё абсалютна бескарысна, як правіла, таму што вядзе да такога перанасычэння алертамі, перанасычэння паведамленнямі ад маніторынгу, калі чалавек, па-першае, кожны раз павінен іх інтэрпрэтаваць, гэта значыць вызначаць: ці азначае значэнне метрыкі неабходнасць нейкіх дзеянняў. А па-другое, ён проста перастае заўважаць усе гэтыя алерты, калі ў асноўным ніякіх дзеянняў ад яго пры гэтым не патрабуецца. Гэта значыць добрае правіла маніторынгу і самае першае правіла, калі рэалізуецца SRE у тым, што апавяшчэнне павінна прыходзіць толькі тады, калі патрабуецца дзеянне.
У стандартным выпадку ёсць 3 узроўня падзей. Ёсць алерты, ёсць цікеты, ёсць логі. Алерты - гэта ўсё тое, што патрабуе ад вас неадкладнага дзеяння. Гэта значыць, вось, усё зламалася, трэба правіць прама зараз. Тыкеты - гэта тое, што патрабуе адкладзенага дзеяння. Так, трэба нешта рабіць, трэба нешта рабіць уручную, аўтаматызацыя не справілася, але не абавязкова рабіць гэта цягам наступных некалькіх хвілін. Логі - гэта ўсё тое, што не патрабуе дзеяння, і ў цэлым пры добрым развіцці падзей, ніхто ніколі не будзе іх чытаць. Чытаць логі трэба будзе толькі калі ўжо ў рэтраспектыве аказалася, што нейкі час нешта ламалася, мы пра гэта не ведалі. Або трэба правесці нейкае расследаванне. Але ў цэлым усё тое, што не патрабуе ніякіх дзеянняў, ідзе ў логі.
Як пабочны эфект ад усяго гэтага, калі мы вызначылі, якія падзеі патрабуюць дзеянняў і добра апісалі, якімі гэтыя дзеянні павінны быць, гэта азначае, што дзеянне можна аўтаматызаваць. Гэта значыць, што атрымоўваецца. Мы ідзём ад алерта. Ідзем да дзеяння. Ідзем да апісання гэтага дзеяння. І далей мы ідзем да аўтаматызацыі. Гэта значыць, што любая аўтаматызацыя пачынаецца з рэакцыі на падзею.
Ад маніторынгу мы пераходзім да тэрміна, які называецца Observability. Таксама такі крыху хайп вакол гэтага слова апошнія некалькі гадоў. І мала хто разумее, што гэта значыць па-за кантэкстам. Але асноўны сэнс у тым, што Observability гэта метрыка празрыстасці сістэмы. Калі нешта пайшло не так, наколькі хутка вы зможаце вызначыць, што менавіта пайшло не так, і якім быў стан сістэмы ў гэты момант. З пункту гледжання кода: у якой функцыі адбыўся збой, у якім сэрвісе адбыўся збой. Якім быў стан, напрыклад, унутраных зменных, канфігурацыі. З пункту гледжання інфраструктуры гэта ў якой зоне даступнасці адбыўся збой, а калі ў вас стаіць які-небудзь Kubernetes, то ў якім подзе адбыўся збой, якім быў стан пода. І адпаведна Observability мае прамую залежнасць ад MTTR. Чым вышэй Observability сэрвісу, тым прасцей вызначыць памылку, тым прасцей выправіць памылку, тым прасцей аўтаматызаваць памылку, тым ніжэй MTTR.
Калі перайсці да невялікіх кампаній зноў, то вельмі часта пытаюцца, нават вось зараз, як паступаць з памерам каманды, і ці трэба ў невялікай камандзе наймаць асобнага SRE. Ужо пра гэта казаў крыху раней. На першых этапах развіцця стартапа ці, напрыклад, каманды гэта зусім не абавязкова, таму што SRE можна зрабіць пераходнай роляй. І гэта крыху ажывіць каманду, таму што ёсць хоць нейкая разнастайнасць. І плюс падрыхтуе людзей да таго, што з ростам, увогуле-то, абавязкі SRE будуць мяняцца вельмі значна. Калі наймаць чалавека, то ў яго, зразумела, ёсць нейкія чаканні. І гэтыя чаканні з часам не зменяцца, а вось патрабаванні зменяцца вельмі моцна. Таму як бы наймаць SRE дастаткова складана на ранніх этапах. Выгадаваць свайго значна прасцей. Але пра гэта варта задумацца.
Адзінае, мусіць, выключэнне, гэта калі ёсць вельмі цвёрдыя і добра вызначаныя патрабаванні па росце. Гэта значыць, у выпадку стартапа гэта можа быць нейкі ціск ад інвестараў, нейкі прагноз на рост адразу ў некалькі разоў. Тады наём SRE, увогуле, апраўданы, таму што яго можна абгрунтаваць. У нас ёсць патрабаванні па росце, нам патрэбен чалавек, які будзе адказваць за тое, што пры такім росце нічога не зламаецца.
Яшчэ адно пытанне. Як быць, калі некалькі разоў распрацоўнікі пілуюць фічу, якая праходзіць тэсты, але ламае прод, нагружае базу, ламае іншыя фічы, які працэс укараніць. Адпаведна ў гэтым выпадку ўкараняецца якраз бюджэт на памылкі. І частка сэрвісаў, частка фіч тэстуецца ўжо адразу ў продзе. Гэта можа быць canary, калі толькі невялікай колькасці карыстачоў, але ўжо ў продзе разгортваецца фіча, але ўжо з разлікам на тое, што калі нешта зламаецца, напрыклад, у паловы адсотка ўсіх карыстачоў, тое ўсё яшчэ ўкладзецца ў бюджэт на памылкі. Адпаведна так, памылка будзе, у часткі карыстачоў усё зламаецца, але мы ўжо казалі аб тым, што гэта звычайна.
Было пытанне па прыладах SRE. Гэта значыць, ці ёсць нешта канкрэтнае, што выкарыстоўвалі б SRE, і не выкарыстоўвалі б усе астатнія. Насамрэч ёсць нейкія вузкаспецыялізаваныя ўтыліты, ёсць нейкі софт, які, напрыклад, імітуе нагрузкі ці займаецца canary A/B тэставаннем. Але ў асноўным інструментар SRE гэта тое, што ўжо выкарыстоўваюць вашыя распрацоўшчыкі. Таму што SRE узаемадзейнічае напрамую з камандай распрацоўкі. І калі ў вас будзе розны інструментар, тое атрымаецца, што сыходзіць час на сінхранізацыю. Асабліва калі SRE працуюць у вялікіх камандах, у вялікіх кампаніях, дзе каманд можа быць некалькі, тут вельмі дапаможа менавіта стандартызацыя менавіта ў маштабах кампаніі, таму што калі ў 50 камандах выкарыстоўваецца 50 розных утыліт, гэта азначае, што SRE павінен ведаць іх усе. І гэтага зразумела ніколі не адбудзецца. І якасць працы, якасць кантролю прынамсі часткі каманд значна зменшыцца.
У нас вэбінар падыходзіць паступова да канца. Нейкія асноўныя рэчы я паспеў расказаць. Зразумела, нічога пра SRE нельга расказаць і зразумець за гадзіну. Але я спадзяюся, што атрымалася перадаць гэтую выяву думкі, асноўныя ключавыя моманты. І далей можна будзе, калі цікава, паглыбляцца ў тэму, вучыцца самастойна, глядзець на тое, як гэта ўкараняецца ў іншых людзей, іншых кампаніях. І адпаведна ў пачатку лютага прыехаць да нас на Слёрм SRE.
Слёрм SRE - гэта трохдзённы інтэнсіўны курс, у якім будзе распавядацца прыкладна аб тым, што цяпер распавядаю я, але са значна большай глыбінёй, з рэальнымі кейсамі, з практыкай, увесь інтэнсіў накіраваны на практычную працу. Людзей размяркуюць па камандах. Вы ўсё будзеце працаваць над рэальнымі кейсамі. Адпаведна ў нас ёсць інструктары з Booking.com Іван Круглоў і Бэн Тайлер. У нас ёсць выдатны Яўген Варава з Гугла, з Сан Францыска. І я таксама вам што-небудзь раскажу. Таму абавязкова прыязджайце да нас.
Такім чынам, спіс літаратуры. Ёсць спасылкі па SRE. на тую самую кнігу, дакладней на 2 кнігі аб SRE, напісаныя Гуглом. Яшчэ адна , дзе крыху падрабязней раскрываюцца тэрміны і іх ужыванне. Наступныя 3 гэта даклады па SRE у розных кампаніях. Першая - , гэта кейнот ад Бэна Трэйнера з гугл. Другая - . Трэцяя зноў жа аб . Чацвёрты даклад ад , Які мае ўсяго 5 ключавых SRE супрацоўнікаў на 190 краін. Вельмі цікава паглядзець на ўсё гэта, таму што як DevOps значыць вельмі розныя рэчы для розных кампаній і нават розных каманд, так і SRE мае вельмі рознае кола абавязкаў, нават у кампаніях падобных памераў.
Яшчэ 2 спасылкі па прынцыпах chaos ingeneering: , . І ў канцы ёсць 3 спісы з серыі Awesome Lists пра , пра і пра . Спіс па SRE неверагодна велізарны, не абавязкова праходзіць яго ўвесь, там каля 200 артыкулаў. Вельмі рэкамендаваны адтуль артыкулы пра capacity planning і пра blameless postmortem.
Цікавая артыкул:
Дзякуй, што слухалі мяне ўвесь гэты час. Спадзяюся, што вы нечаму навучыліся. Спадзяюся, што ў вас ёсць дастаткова матэрыялаў, каб навучыцца яшчэ большаму. І да сустрэчы. Спадзяюся ў лютым.
Вебінар вёў Эдуард Мядзведзеў.
PS: для тых, хто кахае чытаць, Эдуард даў спіс літаратуры. Тых, хто аддае перавагу разбірацца на практыцы, чакаем на .
Крыніца: habr.com