SRE (Site Reliability Engineering) – падыход да забеспячэння даступнасці вэб-праектаў. Лічыцца фрэймворкам для DevOps і кажа як дамагчыся поспеху ва ўжыванне DevOps-практык. У гэтым артыкуле пераклад кнігі ад Google. Гэты пераклад я рыхтаваў самастойна і належыў на ўласны досвед разумення працэсаў маніторынгу. У тэлеграм-канале и я публікаваў таксама спасылку на пераклад 4 раздзела гэтай жа кнігі аб мэтах узроўня абслугоўвання.
Пераклад па ката. Прыемнага чытання!
У каманд SRE кампаніі Google ёсць базавыя прынцыпы і лепшыя практыкі для стварэння паспяховых сістэм маніторынгу і апавяшчэнняў. У гэтым раздзеле прыводзяцца рэкамендацыі аб тым, якія праблемы могуць сустрэцца наведвальніку вэб-старонкі і як вырашаць праблемы, якія абцяжарваюць адлюстраванне вэб-старонак.
вызначэння
Адзінага слоўнікавага запасу, які выкарыстоўваецца для абмеркавання тэм, звязаных з маніторынгам, не існуе. Нават у Google, прыведзеныя ніжэй тэрміны не з'яўляюцца агульнаўжывальнымі, але мы пералічым найболей распаўсюджаныя інтэрпрэтацыі.
Маніторынг
Збор, апрацоўка, агрэгаванне і адлюстраванне колькасных дадзеных у рэальным часе аб сістэме: колькасць запытаў і тыпы запытаў, колькасць памылак і тыпы памылак, час апрацоўкі запыту і час працы сервера.
Маніторынг White-box
Маніторынг, заснаваны на паказчыках, якія адлюстроўваюцца ўнутранымі кампанентамі сістэмы, уключаючы часопісы, метрыкі прафілявання віртуальнай машыны Java або апрацоўшчыка HTTP, якія генеруюць унутраную статыстыку.
Маніторынг Black-box
Тэставанне паводзін прыкладання з пункту гледжання карыстальніка.
Dashboard (панэлі маніторынгу)
Інтэрфейс (звычайна вэб), які дае агляд асноўных паказчыкаў здароўя сэрвісаў. На панэлі маніторынгу могуць быць фільтры, магчымасць выбару паказу паказчыкаў і г. д. Інтэрфейс створаны, каб выявіць найбольш важныя для карыстальнікаў паказчыкі. На панэлі маніторынгу таксама могуць адлюстроўвацца інфармацыя для супрацоўнікаў тэхнічнай падтрымкі: чарга запытаў, спіс высокапрыярытэтных памылак, замацаваны інжынер для зададзенай зоны адказнасці.
Alert (апавяшчэнне)
Апавяшчэнні, прызначаныя для атрымання чалавекам па электроннай пошце ці іншым шляхам, якія могуць быць ініцыяваныя ў выніку ўзнікнення памылак або павелічэння чаргі запытаў. Апавяшчэнні класіфікуюцца як: цікеты, абвесткі па электроннай пошце і паведамленні ў месэнджары.
Root cause (каранёвая прычына)
Дэфект праграмнага забеспячэння або чалавечы фактар, якія пры ўхіленні не павінны ўзнікаць зноў. Праблема можа мець некалькі асноўных прычын: недастатковая аўтаматызацыя працэсаў, дэфект праграмнага забеспячэння, недастатковая прапрацоўка логікі працы прыкладання. Кожны з гэтых фактараў можа быць першапрычынай, і кожны з іх павінен быць ухілены.
Node and machine (нода і машына)
Узаемазаменныя паняцці, каб пазначыць адзін асобнік працуючага прыкладання на фізічным серверы, віртуальнай машыне або кантэйнеры. На адной машыне можа знаходзіцца некалькі сервісаў. Сэрвісы могуць быць:
- звязаныя адзін з адным: напрыклад, сервер кэшавання і вэб-сервер;
- не звязаныя сэрвісы на адзіным апаратным забеспячэнні: напрыклад, рэпазітар кода і майстар для сістэмы канфігурацыі, такія як або .
Штурхаць
Любое змяненне канфігурацыі праграмнага забеспячэння.
Навошта патрэбен маніторынг
Ёсць некалькі прычын, чаму прыкладанні трэба ставіць на маніторынг:
Аналіз працяглых трэндаў
Наколькі вялікая база даных і як хутка яна расце? Як мяняецца штодзённая колькасць карыстальнікаў?
Параўнанне хуткадзейнасці
Ці хутчэй выконваюцца запыты на Acme Bucket of Bytes 2.72 у параўнанні з Ajax DB 3.14? Наколькі лепш кэшуюцца запыты пасля з'яўлення дадатковай ноды? Ці стаў павольней працаваць сайт у параўнанні з мінулым тыднем?
Alerting (апавяшчэння)
Нешта зламалася і нехта павінен гэта паправіць. Ці нешта хутка зламаецца і нехта павінен гэта хутка праверыць.
Стварэнне дашбордаў
Дашборды павінны адказваць на асноўныя пытанні і ўключаць нешта з - Затрымкі (latency), трафік (traffic), памылкі (errors) і велічыню нагрузкі (saturation).
Правядзенне рэтраспектыўнага аналізу (debugging)
Затрымка апрацоўкі запыту павялічылася, а што яшчэ здарылася прыкладна ў гэты час?
Сістэмы маніторынгу карысныя як крыніца даных для сістэм бізнес-аналітыкі і спрашчэння аналізу інцыдэнтаў па бяспецы. Паколькі гэтая кніга прысвечана інжынерным абласцям, у якіх SRE валодаюць экспертызай, мы не будзем абмяркоўваць тут методыкі маніторынгу.
Маніторынг і абвесткі дазваляюць сістэме распавесці, калі яна зламалася, ці вось-вось зламаецца. Калі сістэма не можа аўтаматычна аднаўляць сябе, мы хочам, каб апавяшчэнне аналізаваў чалавек, вызначыў, ці актуальная праблема, устараніў і вызначыў яе асноўны чыннік. Калі вы не ажыццяўляеце аўдыт кампанентаў сістэмы, вы ніколі не атрымаеце апавяшчэнне проста таму, што «нешта здаецца крыху дзіўным».
Нагрузка абвесткамі чалавека - даволі дарагое выкарыстанне часу супрацоўніка. Калі супрацоўнік працуе, апавяшчэнне перарывае працоўны працэс. Калі супрацоўнік знаходзіцца дома, абвестка перарывае асабісты час і, магчыма, сон. Калі абвесткі адбываюцца занадта часта, супрацоўнікі бегла іх праглядаюць, адкладаюць або ігнаруюць уваходныя папярэджанні. Час ад часу яны ігнаруюць сапраўднае апавяшчэнне, якое замаскіравана шумавымі падзеямі. Перапынкі ў сэрвісе могуць працягвацца працяглы час, паколькі шумавыя падзеі замінаюць хуткай дыягностыцы і ўхіленню праблемы. Эфектыўныя сістэмы абвесткі маюць добрыя суадносіны сігнал/шум.
Вызначэнне разумных чаканняў ад сістэмы маніторынгу
Настройка маніторынгу комплекснага прыкладання - сама па сабе складаная інжынерная задача. Нават маючы значную інфраструктуру інструментаў збору, адлюстравання і абвесткі, каманда Google SRE з 10-12 членамі звычайна ўключае аднаго або двух чалавек, асноўнае прызначэнне якіх у стварэнні і абслугоўванні сістэм маніторынгу. Гэтая колькасць з часам скарацілася, па меры таго, як мы абагульняем і цэнтралізуем інфраструктуру маніторынгу, але кожная каманда SRE звычайна мае прынамсі аднаго супрацоўніка які займаецца толькі маніторынгам. Павінны сказаць, што хаця даволі цікава назіраць за дашбордамі сістэмы маніторынгу, каманды SRE старанна пазбягаюць сітуацый, якія патрабуюць ад кагосьці глядзець на экран, каб сачыць за праблемамі.
У цэлым, Google перайшоў на простыя і хуткія сістэмы маніторынгу з аптымальнымі прыладамі постфактум-аналізу. Мы пазбягаем "чарадзейных" сістэм, якія спрабуюць прагназаваць парогавыя значэння або аўтаматычна выяўляюць першапрычыну. Сэнсары, якія выяўляюць непрадугледжанае змесціва ў запытах канчатковых карыстачоў, з'яўляюцца адзіным контрпрыкладам; датуль пакуль гэтыя сэнсары застаюцца простымі, яны дазваляюць хутка выявіць чыннікі сур'ёзных анамалій. Іншыя фарматы выкарыстання дадзеных маніторынгу, такія як планаванне магутнасцей або прагназаванне трафіку ўяўляюць з сябе больш складаную задачу. Назіранне, якое праводзіцца на працягу вельмі доўгага часу (месяцы ці гады) з нізкай частатой дыскрэтызацыі (гадзіны ці дні), дазволіць выявіць доўгачасовую тэндэнцыю.
Каманда Google SRE працавала са зменным поспехам са складанымі іерархіямі залежнасцяў. Мы рэдка выкарыстоўваем такія правілы, як «калі я даведаўся, што база дадзеных стала павольна працаваць, атрымліваю апавяшчэнне аб запаволенні базы дадзеных, інакш атрымліваю апавяшчэнне аб павольна які працуе сайце». Правілы, заснаваныя на залежнасцях, звычайна адносяцца да нязменных частак нашай сістэмы, такім як сістэма для фільтрацыі карыстацкага трафіку да цэнтра апрацоўкі дадзеных. Напрыклад, «калі наладжана фільтраванне трафіку да цэнтра апрацоўкі дадзеных, не папярэджвайце мяне аб затрымках апрацоўкі карыстацкіх запытаў» - гэта адно агульнае правіла для абвестак ад цэнтра апрацоўкі дадзеных. Нямногія каманды ў Google падтрымліваюць складаныя іерархіі залежнасцяў, таму што наша інфраструктура мае пастаянную хуткасць бесперапыннага рэфактарынгу.
Некаторыя з ідэй, апісаных у гэтым раздзеле, па-ранейшаму актуальныя: заўсёды ёсць магчымасць хутчэй рухацца ад сімптому да першапрычыны, асабліва ў пастаянна змяняюцца сістэмах. Таму, хоць у гэтым раздзеле выкладзены некаторыя мэты для сістэм маніторынгу і спосабы дасягнення гэтых мэт, важна, каб сістэмы маніторынгу былі простыя і зразумелыя ўсім у камандзе.
Аналагічна, каб падтрымліваць нізкі ўзровень шуму і высокі ўзровень сігналу, падыходы да маніторынгу аб'ектаў, па якіх ажыццяўляецца абвесткі, павінны быць вельмі простымі і надзейнымі. Правілы, якія генеруюць папярэджанні для людзей, павінны быць простымі для разумення і ўяўляць сабой відавочную праблему.
Сімптомы супраць прычын
Ваша сістэма маніторынгу павінна адказваць на два пытанні: "што зламалася" і "чаму зламалася".
"Што зламалася" кажа аб сімптоме, а "чаму зламалася" аб прычыне. У табліцы ніжэй прыведзены прыклады такіх звязкаў.
сімптом
Прычына
Атрыманне HTTP-памылкі 500 ці 404
Серверы базы дадзеных адхіляюць падлучэнні
Павольныя адказы сервера
Высокая ўтылізацыя CPU або пашкоджанне кабеля Ethernet
Карыстальнікі ў Антарктыцы не атрымліваюць гіфкі з катамі
Ваша CDN ненавідзіць навукоўцаў і каціных, такім чынам, некаторыя IP-адрасы апынуліся ў чорным спісе
Прыватны кантэнт стаў даступны адусюль
Накатванне новага рэлізу ПЗ прымусіла файрвол забыць усе ACL і пускае ўсіх запар
«Што» і «чаму» - адны з найважнейшых цаглінак для стварэння добрай сістэмы маніторынгу з максімум сігналу і мінімумам шуму.
Black-box супраць White-box
Мы спалучаем шырокі White-box маніторынг са сціплым Black-box маніторынгам для крытычных метрык. Самы просты спосаб параўнаць Black-box з White-box – гэта тое, што Black-box арыентаваны на сімптомы і ўяўляе сабой рэактыўны, а не праактыўны маніторынг: "сістэма прама цяпер працуе некарэктна". White-box залежыць ад магчымасцяў унутранай праверкі сістэм: часопісаў падзей ці вэб-сервераў. Такім чынам, White-box дазваляе выяўляць будучыя праблемы, няспраўнасці, якія выглядаюць як паўторная перадача запыту і т. д.
Звярніце ўвагу, што ў шматслаёвай сістэме сімптом у зоне адказнасці аднаго інжынера з'яўляецца сімптомам у зоне адказнасці іншага інжынера. Напрыклад, знізілася прадукцыйнасць базы даных. Павольныя чытанні з базы дадзеных з'яўляюцца сімптомам для SRE па базах дадзеных, які іх выяўляе. Тым не менш, для SRE па франтэндзе, які назірае павольны вэб-сайт, прычынай таго ж павольнага чытання базы дадзеных з'яўляецца павольная праца базы дадзеных. Таму White-box маніторынг часам арыентаваны на сімптомы, а часам на прычыны, у залежнасці ад таго, наколькі ён шырокі.
Пры зборы тэлеметрыі для адладкі неабходзен White-box маніторынг. Калі вэб-серверы павольна рэагуюць на запыты, звязаныя з базай дадзеных, вам трэба ведаць, наколькі хутка вэб-сервер узаемадзейнічае з базай дадзеных і наколькі хутка яна выдае адказ. У адваротным выпадку, вы не зможаце адрозніць павольны сервер базы дадзеных ад сеткавай праблемы паміж вэб-серверам і базай дадзеных.
Black-box маніторынг мае ключавую перавагу пры адпраўцы абвестак: вы ініцыюеце адпраўку апавяшчэння атрымальніку, калі праблема ўжо прывяла да ўзнікнення рэальных сімптомаў. З іншага боку, для яшчэ не ўзніклай, але будучай праблемы Black-box маніторынг бескарысны.
Чатыры залатыя сігналы
Чатыры залатыя сігналы маніторынгу - гэта затрымка, трафік, памылкі і насычанасць. Калі вы можаце вымераць толькі чатыры паказчыкі карыстацкай сістэмы, засяродзьцеся на гэтых чатырох.
затрымка
Час, неабходны для апрацоўкі запыту. Важна адрозніваць затрымку паспяховых і няўдалых запытаў. Напрыклад, памылка HTTP 500, выкліканая стратай злучэння з базай дадзеных або іншым бэкэндам можа быць дыягнаставана вельмі хутка, аднак, памылка HTTP 500 можа паказваць на няўдалы запыт. Выяўленне ўплыву памылкі 500 на агульную затрымку можа прывесці да памылковых высноў. З іншага боку, марудная памылка нават хуткай памылкі! Таму важна адсочваць затрымку з памылкай, а не проста адфільтроўваць памылкі.
трафік
Колькасць запытаў да вашай сістэмы, вымяраецца ў высокаўзроўневымі метрыкамі сістэмы. Для вэб-службы гэтае вымярэнне звычайна ўяўляе колькасць HTTP-запытаў у секунду, падзеленыя па характары запытаў (напрыклад, статычны ці дынамічны кантэнт). Для сістэмы струменевай перадачы гуку гэтае вымярэнне можа быць сканцэнтравана на хуткасці ўводу-вываду сеткі ці колькасці адначасовых сеансах. Для сістэмы захоўвання ключ-значэнне такое вымярэнне можа з'яўляцца транзакцыямі ці вынікамі пошуку за секунду.
Памылкі
Гэта частата няўдалых запытаў, якія відавочна (напрыклад, HTTP 500), няяўна (напрыклад, HTTP 200, але ў спалучэнні з няправільным кантэнтам) ці палітыкай (напрыклад, «Калі вы зафіксавалі адказ за адну секунду, любы аднасекундны з'яўляецца памылкай »). Калі кодаў адказу пратаколу HTTP недастаткова для выражэння ўсіх умоў збою, для выяўлення частковай адмовы могуць спатрэбіцца другасныя (унутраныя) пратаколы. Маніторынг усіх такіх памылковых запытаў можа аказацца неінфарматыўным, у той час як скразныя сістэмныя тэсты дапамогуць выявіць, што вы апрацоўваеце няправільны кантэнт.
Насычэнне
Метрыка паказвае наколькі інтэнсіўна выкарыстоўваецца ваш сэрвіс. Гэта мера сістэмнага маніторынгу, якая выяўляе рэсурсы, якія найболей абмежаваныя (напрыклад, у сістэме з абмежаванай памяццю, паказвае памяць, у сістэме з абмежаваннямі ўводу/высновы паказваецца колькасць уводаў-высноваў). Звярніце ўвагу, што многія сістэмы пагаршаюць прадукцыйнасць, перш чым яны дасягаюць 100% выкарыстання, таму наяўнасць мэты выкарыстання мае важнае значэнне.
У складаных сістэмах насычэнне можа быць дапоўнена вымярэннем нагрузкі больш высокага ўзроўня: ці можа ваша сэрвіс належным чынам апрацоўваць падвойны трафік, апрацоўваць толькі на 10% больш трафіку ці апрацоўваць яшчэ менш трафіку, чым у наш час? Для простых сэрвісаў, у якіх няма параметраў, якія змяняюць складанасць запыту (напрыклад, "Дайце мне нічога" ці "Мне трэба унікальнае адно цэлае манатоннае цэлае лік"), якія рэдка мяняюць канфігурацыю, статычнае значэнне тэсту нагрузкі можа быць адэкватным, Аднак, як абмяркоўвалася ў папярэднім абзацы, большасць службаў павінны выкарыстоўваць ускосныя сігналы, такія як утылізацыя CPU або прапускную здольнасць сеткі, якія маюць вядомую верхнюю мяжу. Павышэнне затрымкі часта з'яўляецца асноўным паказчыкам насычэння. Вымярэнне часу водгуку 99-га адсотка ў невялікім акне (напрыклад, адна хвіліна) можа даць вельмі ранні сігнал насычэння.
Нарэшце, насычэнне таксама злучана з прадказаннямі аб якое насоўваецца насычэнні, напрыклад: «Падобна, ваша база дадзеных запоўніць цвёрдую кружэлку за 4 гадзіны».
Калі вы вымяраеце ўсе чатыры залатыя сігналы і, калі ўзнікае праблема з адной з метрык (ці, у выпадку насычэння, амаль праблема), апавяшчаеце чалавека, ваш сэрвіс будзе больш-менш ахоплены маніторынгам.
Турбота аб «хвасце» (або інструментацыя і прадукцыйнасць)
Пры стварэнні сістэмы маніторынгу "з нуля" ўзнікае спакусу распрацаваць сістэму, заснаваную на сярэдніх значэннях: сярэдняя затрымка, сярэдняя ўтылізацыя CPU вузлоў або сярэдняя запоўненасць баз дадзеных. Небяспека двух апошніх прыкладаў відавочная: працэсары і базы дадзеных утылізуюцца вельмі непрадказальным чынам. Тое ж самае тычыцца затрымкі. Калі вы запускаеце вэб-сэрвіс з сярэдняй затрымкай у 100 мс пры 1000 запытах у секунду, 1% запытаў можа заняць 5 секунд. Калі карыстачы залежаць ад некалькіх такіх вэб-сэрвісаў, 99-й процентиль аднаго бэкэнда можа лёгка стаць медыянным часам адказу інтэрфейсу.
Найпросты спосаб размежавання паміж павольным сярэднім і вельмі павольным «хвастом» запытаў складаецца ў тым, каб збіраць вымярэнні запытаў, выяўленыя ў статыстыцы (падыходны інструмент для адлюстравання – гістаграмы), а не фактычныя затрымкі: колькі запытаў абслужыў сэрвіс, якія займалі паміж 0 мс і 10 мс, паміж 10 мс і 30 мс, паміж 30 мс і 100 мс, паміж 100 мс і 300 мс і т. д. Пашырэнне межаў гістаграмы прыблізна экспанентна (з прыкладным каэфіцыентам 3) часта з'яўляецца простым спосабам візуалізацыі размеркавання запытаў.
Выбар прыдатнай ступені дэталізацыі для вымярэнняў
Розныя элементы сістэмы павінны вымярацца з рознай ступенню дэталізацыі. Напрыклад:
- Назіранне за ўтылізацыяй загрузкі CPU у пэўны прамежак часу не пакажа працяглыя выкіды, якія прыводзяць да высокіх затрымак.
- З іншага боку, для вэб-сэрвісу, арыентаванага на не больш за 9 гадзін прастояў у год (99,9% гадавога часу безадмоўнай працы), праверка на HTTP адказ 200 больш аднаго ці двух разоў у хвіліну будзе, верагодна, залішне частай.
- Гэтак жа праверка наяўнасці вольнага месца на цвёрдым дыску для 99,9% даступнасці больш за адзін раз кожныя 1-2 хвіліны, верагодна, не патрэбна.
Паклапаціцеся пра тое, як вы структуруеце гранулярнасць вымярэнняў. Перыядычнасць збору загрузкі CPU 1 раз у секунду можа даць цікавыя дадзеныя, але такія частыя вымярэнні могуць быць вельмі дарагімі для збору, захоўванні і аналізу. Калі мэта маніторынгу патрабуе высокай гранулярнасці і не патрабуе высокай хуткасці рэакцыі, вы можаце паменшыць гэтыя выдаткі, наладзіўшы збор метрык на серверы, а затым наладзіўшы знешнюю сістэму для збору і агрэгавання гэтых метрык. Вы маглі б:
- Вымяраць загрузку CPU кожную секунду.
- Зрэзаць дэталізацыю да 5%.
- Агрэгаваць метрыкі кожную хвіліну.
Гэтая стратэгія дазволіць збіраць дадзеныя з высока гранулярнасцю, не выпрабоўваючы высокіх накладных выдаткаў на аналіз і захоўванне.
Як мага прасцей, але не прасцей
Накладанне розных патрабаванняў сябар на сябра можа прывесці да вельмі складанай сістэмы маніторынгу. Напрыклад, ваша сістэма можа абзавесціць наступнымі якія ўскладняюць элементамі:
- Абвесткі згодна з розных парогавых значэнняў для затрымкі апрацоўкі запытаў, у розных працэнты, па ўсіх відах розных паказчыкаў.
- Напісанне дадатковага кода для выяўлення і выяўленні магчымых прычын.
- Стварэнне звязаных дашбордаў для кожнай з магчымых прычын праблем.
Крыніцы патэнцыйнага ўскладнення ніколі не сканчаюцца. Як і ўсе праграмныя сістэмы, маніторынг можа ўскладніцца настолькі, што стане далікатным, складаным для змен і абслугоўвання.
Таму праектуйце сваю сістэму маніторынгу з мэтай як мага больш яе спрасціць. Выбіраючы, што трэба адсочваць, падушыце наступнае:
- Правілы, якія часцей за ўсё ловяць рэальныя інцыдэнты, павінны быць максімальна простымі, прадказальнымі і надзейнымі.
- Канфігурацыя для збору дадзеных, агрэгацыі і абвесткі, якія рэдка выконваюцца (напрыклад, менш за раз у квартал для некаторых каманд SRE), павінна быць выдаленая.
- Метрыкі, якія збіраюцца, але не адлюстроўваюцца на якой-небудзь папярэдняй панэлі і не выкарыстоўваюцца якім-небудзь папярэджаннем, з'яўляюцца кандыдатамі на выдаленне.
У Google базавы збор і агрэгацыя паказчыкаў, у спалучэнні з абвесткамі і дашбордамі, добра працуюць як адносна аўтаномная сістэма (Фактычна сістэма маніторынгу Google разбіта на некалькі падсістэм, але звычайна людзі ведаюць аб усіх аспектах гэтых падсістэм). Можа ўзнікнуць спакуса спалучаць маніторынг з іншымі метадамі праверкі складаных сістэм: падрабязнае прафіляванне сістэмы, адладка працэсу, адсочванне дэталяў аб выключэннях або збоях, тэсціраванне нагрузкі, збор і аналіз часопісаў або праверка трафіку. У той час як большасць з гэтых рэчаў маюць агульныя рысы з асноўным маніторынгам, іх змешванне прывядзе да занадта вялікай колькасці вынікаў у створыць складаную і далікатную сістэму. Як і ў шматлікіх іншых аспектах распрацоўкі праграмнага забеспячэння, падтрымка розных сістэм з выразнымі, простымі, слаба злучанымі кропкамі інтэграцыі з'яўляецца лепшай стратэгіяй (напрыклад, выкарыстанне вэб-API для вымання зводных дадзеных у фармаце, які можа заставацца сталым на працягу працяглага перыяду часу).
Звязванне прынцыпаў разам
Прынцыпы, якія абмяркоўваюцца ў гэтым раздзеле, могуць быць аб'яднаны ў філасофію маніторынгу і абвесткі, якая адобрана і выконваецца ў камандах Google SRE. Захаванне гэтай філасофіі маніторынгу пажадана, яна з'яўляецца добрай адпраўной кропкай для стварэння або перагляду методыкі абвестак і можа дапамагчы задаваць правільныя пытанні службе эксплуатацыі незалежна ад памеру вашай арганізацыі ці складанасці сэрвісу ці сістэмы.
Пры стварэнні правіл маніторынгу і абвесткі, задаючы наступныя пытанні, вы можаце пазбегнуць ілжывых спрацоўванняў і залішніх абвестак:
- Ці выяўляе гэтае правіла, інакш не якое выяўляецца стан сістэмы, якое з'яўляецца тэрміновым, што заклікае да дзеяння і непазбежна ўплываюць на карыстача?
- Ці магу я ігнараваць гэтае папярэджанне, ведаючы, што яно дабраякаснае? Калі і чаму я магу ігнараваць гэтае папярэджанне і як я магу пазбегнуць гэтага сцэнара?
- Ці азначае гэта апавяшчэнне, што карыстачы падвяргаюцца негатыўнаму ўздзеянню? Ці існуюць сітуацыі, калі карыстачы не падвяргаюцца негатыўнаму ўздзеянню, напрыклад, з-за фільтраванні трафіку ці пры выкарыстанні тэставых сістэм, абвесткі па якіх варта адфільтраваць?
- Ці магу я прыняць меры ў адказ на гэтае апавяшчэнне? Ці з'яўляюцца гэтыя меры тэрміновымі ці яны могуць чакаць да раніцы? Ці можна бяспечна аўтаматызаваць дзеянне? Ці будзе гэта дзеянне доўгатэрміновым рашэннем або кароткатэрміновым абыходным рашэннем?
- Некаторыя людзі атрымліваюць некалькі абвестак па гэтай праблеме, таму ці можна скараціць іх колькасць?
Гэтыя пытанні адлюстроўваюць фундаментальную філасофію па абвестках і сістэмам абвесткі:
- Кожны раз, калі прыходзіць апавяшчэнне, я павінен неадкладна рэагаваць. Я магу неадкладна рэагаваць некалькі разоў у дзень, перш чым стамлюся.
- Кожнае апавяшчэнне павінна быць актуальна.
- Кожная рэакцыя на апавяшчэнне павінна патрабаваць умяшанні чалавека. Калі апавяшчэнне можа апрацоўвацца аўтаматычна, яна не павінна прыходзіць.
- Абвесткі павінны быць аб новай праблеме або падзеі, якога не было раней.
Такі падыход сцірае пэўныя адрозненні: калі абвестка задавальняе папярэднім чатыром умовам, не мае значэння, ці адпраўляецца абвестка з сістэмы White-box маніторынгу або Black-Box. Гэты падыход таксама ўзмацняе пэўныя адрозненні: лепш марнаваць значна больш намаганняў на выяўленне сімптомаў, чым на прычыны; калі справа даходзіць да прычын, турбавацца трэба толькі аб непазбежных прычынах.
Маніторынг у доўгатэрміновай перспектыве
У сучасных прадуктыўных асяродках сістэмы маніторынгу адсочваюць пастаянна развіваецца прадуктыўную сістэму з зменлівымі архітэктурай праграмнага забеспячэння, характарыстыкамі нагрузкі і мэтавай прадукцыйнасцю. Абвесткі, якія ў цяперашні час складана аўтаматызаваць, могуць стаць частай з'явай, магчыма, нават годнай таго, каб яе вырашыць. У гэты момант хтосьці павінен знайсці і ўхіліць каранёвыя чыннікі праблемы; калі такі дазвол немагчымы, рэакцыя на апавяшчэнне патрабуе поўнай аўтаматызацыі.
Важна, каб рашэнні аб пастаноўцы на маніторынг прымаліся з улікам доўгатэрміновых мэт. Кожнае апавяшчэнне, якое сёння выконваецца, адцягвае чалавека ад удасканалення сістэмы заўтра, таму часта здараецца зніжэнне даступнасці або прадукцыйнасці прадуктыўнай сістэмы на час, неабходнае для паляпшэння сістэмы маніторынгу ў доўгатэрміновай перспектыве. Давайце разгледзім два прыклады, якія ілюструюць гэтую з'яву.
Bigtable SRE: гісторыя пра празмернае апавяшчэнне
Унутраная інфраструктура Google звычайна падаецца і вымяраецца з прывязкай да ўзроўня абслугоўвання (SLO). Шмат гадоў таму SLO службы Bigtable засноўвалася на сярэдняй прадукцыйнасці сінтэтычнай транзакцыі якая імітуе працавальнага кліента. З-за праблем у Bigtable і на больш нізкіх узроўнях стэка захоўвання дадзеных сярэдняя прадукцыйнасць была абумоўлена вялікім хвастом: горшыя 5% запытаў часта былі значна павольней астатніх.
Апавяшчэнні па электроннай пошце адпраўляліся па меры набліжэння да парога SLO, а абвесткі ў мэсанджар адпраўляліся пры перавышэнні SLO. Абодва тыпы папярэджанняў адпраўляліся дастаткова часта, спажываючы непрымальныя аб'ёмы інжынернага часу: каманда выдаткавала значную колькасць часу на разбор абвестак, каб знайсці некалькі, якія сапраўды былі актуальныя. Мы часта прапускалі праблему, якая насамрэч закранала карыстальнікаў, таму што толькі некаторыя з абвестак былі па канкрэтна гэтай праблеме. Многія з абвестак былі нетэрміновымі з-за зразумелых праблем у інфраструктуры і адпрацоўваліся стандартным чынам, альбо наогул ніяк не апрацоўваліся.
Каб выправіць сітуацыю, каманда выкарыстоўвала трохбаковы падыход: прыкладаючы вялікія намаганні для павышэння прадукцыйнасці Bigtable, мы часова вызначылі ў якасці нашай мэты па SLO 75-ю процентиль для затрымкі адказу на запыт. Мы таксама адключылі абвесткі па электроннай пошце, бо іх было так шмат, што марнаваць час на дыягностыку па іх было немагчыма.
Гэтая стратэгія дазволіла нам прадыхнуць, каб пачаць выпраўляць доўгатэрміновыя праблемы ў Bigtable і ніжніх узроўнях стэка захоўвання дадзеных, а не ўвесь час фіксаваць тактычныя праблемы. Інжынеры маглі фактычна выканаць працу, калі іх увесь час не атакавалі абвесткі. У канчатковым рахунку, часовая адтэрміноўка апрацоўкі абвестак дазволіла нам павысіць якасць абслугоўвання.
Gmail: прадказальныя, алгарытмізуемыя адказы людзей
У самым пачатку служба Gmail была пабудавана на мадыфікаванай сістэме кіравання працэсам Workqueue, якая была створана для пакетнай апрацоўкі фрагментаў пошукавага азначніка. Workqueue быў адаптаваны да доўгажывучых працэсаў і пасля ўжыты да Gmail, але некаторыя памылкі ў непразрыстым кодзе планавальніка апынуліся вельмі цяжкавылечнымі.
У той час маніторынг Gmail быў структураваны такім чынам, што папярэджанні спрацоўвалі, калі індывідуальныя задачы адмяняліся з дапамогай Workqueue. Гэты падыход быў не ідэальны, таму што нават у той час Gmail выконваў шмат тысяч задач, кожная з якіх давалася долям працэнта нашых карыстальнікаў. Мы вельмі клапаціліся аб тым, каб карыстачы Gmail карысталіся добрым карыстацкім інтэрфейсам, але адпрацоўка такой колькасці абвестак была недасяжная.
Каб вырашыць гэтую праблему, Gmail SRE стварыў інструмент, які дапамог адладзіць планавальнік як мага лепш, каб мінімізаваць уплыў на карыстальнікаў. У каманды было некалькі дыскусій аб тым, ці трэба проста аўтаматызаваць увесь цыкл ад выяўлення праблемы да ўстаранення да таго часу, пакуль не будзе знойдзена доўгатэрміновае рашэнне, але некаторыя з іх былі занепакоеныя тым, што такое рашэнне затрымае рэальнае выпраўленне праблемы.
Такая напруга была агульным у камандзе і часта адлюстроўвала недавер да самадысцыпліны: у той час як некаторыя чальцы каманды жадаюць даць час для правільнага выпраўлення, іншыя турбуюцца аб тым, што канчатковае выпраўленне забудуцца і часавае ўхіленне праблемы будзе доўжыцца бясконца. Гэтая праблема заслугоўвае ўвагі, бо занадта лёгка часова выпраўляць праблемы, замест таго, каб рабіць выправіць сітуацыю на сталай аснове. Кіраўнікі і тэхнічны персанал гуляюць ключавую ролю ў рэалізацыі доўгатэрміновых выпраўленняў, падтрымліваючы і прыярытызуючы патэнцыйна працяглыя доўгатэрміновыя выпраўленні, нават калі першапачатковая "боль" цішэе.
Рэгулярныя абвесткі, якія паўтараюцца, і алгарытмізаваныя рэакцыі павінны быць чырвоным сцягам. Нежаданне вашай каманды аўтаматызаваць такія абвесткі азначае, што камандзе бракуе ўпэўненасці ў тым, што яны могуць даверыцца алгарытмам. Гэта сур'ёзная праблема, якую трэба вырашаць.
У доўгатэрміновай перспектыве
Агульная тэма злучае прыклады Bigtable і Gmail: канкурэнцыя паміж кароткатэрміновай і доўгатэрміновай даступнасцю. Часта моцны высілак можа дапамагчы далікатнай сістэме дасягнуць высокай даступнасці, але гэты шлях звычайна недаўгавечны, багаты выгараннем каманды і залежнасцю ад невялікай колькасці чальцоў гэтай самай гераічнай каманды.
Кантраляванае, кароткатэрміновае зніжэнне даступнасці часта з'яўляецца балючай, але стратэгічна важнай задачай для доўгатэрміновай стабільнасці сістэмы. Важна не разглядаць кожную абвестку ізалявана, а ўлічваць, ці вядзе агульны ўзровень колькасці абвестак да здаровай, належным чынам даступнай сістэме з жыццяздольнай камандай і спрыяльным прагнозам. Мы аналізуем статыстыку частаты абвестак (звычайна выяўляюцца ў выглядзе інцыдэнтаў за змену, калі інцыдэнт можа складацца з некалькіх злучаных інцыдэнтаў) у штоквартальных справаздачах з кіраўніцтвам, што дазваляе асобам, якія прымаюць рашэнні, стала ўяўляць нагрузку на сістэму абвестак і агульны стан каманды.
Заключэнне
Шлях да здаровага маніторынгу і абвесткам просты і зразумелы. Асноўная ўвага ў ім надаецца сімптомам праблемы, па якіх выконваюцца абвесткі, маніторынг прычыны служыць дапаможным сродкам для адладкі праблем. Маніторынг сімптомаў тым прасцей, чым вышэй вы знаходзіцеся ў стэку, які вы кантралюеце, хоць маніторынг нагрузкі і прадукцыйнасці базы дадзеных павінен выконвацца непасрэдна на ёй самой. Апавяшчэнні па электроннай пошце маюць вельмі абмежаваную карысць і, як правіла, лёгка перарастаюць у шум; замест гэтага вы павінны выкарыстоўваць панэль маніторынгу, якая кантралюе ўсе бягучыя праблемы, па якіх праводзяцца абвесткі па электроннай пошце. Панэль маніторынгу таксама можа быць спалучана з часопісам падзей, каб аналізаваць гістарычныя карэляцыі.
У доўгатэрміновай перспектыве, неабходна дасягненне паспяховага чаргавання абвестак аб сімптомах і непазбежных рэальных праблемах, адаптаваць мэты да забеспячэння таго, каб маніторынг падтрымліваў хуткую дыягностыку.
Дзякуй, што прачыталі пераклад да канца. Падпісвайцеся на мой тэлеграм-канал аб маніторынгу и .
Крыніца: habr.com
