SRE (Site Reliability Engineering) – бұл веб-жобалардың қолжетімділігін қамтамасыз ету тәсілі. Ол DevOps үшін негіз болып саналады және DevOps тәжірибелерін қолдануда табысқа қалай жетуге болатыны туралы айтылады. Осы мақаладағы аударма кітаптар Google-дан. Мен бұл аударманы өзім дайындадым және мониторинг процестерін түсінудегі өз тәжірибеме сүйендім. Телеграм каналында и Мен сондай-ақ қызмет көрсету деңгейінің мақсаттары туралы сол кітаптың 4-тарауының аудармасына сілтеме жарияладым.
Мысықтың аудармасы. Оқудан ләззат алыңыз!
Google компаниясының SRE командаларында сәтті бақылау және хабарландыру жүйелерін құрудың негізгі принциптері мен үздік тәжірибелері бар. Бұл тарауда веб-бетке кіруші қандай мәселелерге тап болуы мүмкін екендігі және веб-беттерді көрсетуді қиындататын мәселелерді шешу жолдары туралы нұсқаулар берілген.
Анықтамалар
Мониторингке қатысты тақырыптарды талқылау үшін қолданылатын бірыңғай сөздік жоқ. Тіпті Google-де төменде келтірілген терминдер жиі қолданылмайды, бірақ біз ең көп тараған түсіндірмелерді тізімдейміз.
Бақылау
Жүйе туралы нақты уақыт режимінде сандық деректерді жинау, өңдеу, жинақтау және көрсету: сұраулар саны мен сұраныс түрлері, қателер саны және қате түрлері, сұранысты өңдеу уақыты және сервердің жұмыс уақыты.
Ақ жәшік мониторингі
Ішкі жүйе құрамдастары, соның ішінде журналдар, Java виртуалды машинасының профильдеу көрсеткіштері немесе ішкі статистиканы жасайтын HTTP өңдегіш көрсеткіштері арқылы көрсетілетін көрсеткіштерге негізделген бақылау.
Қара жәшік мониторингі
Қолданбаның әрекетін пайдаланушының көзқарасы бойынша тексеру.
Бақылау тақтасы
Қызметтердің негізгі денсаулық көрсеткіштеріне шолуды қамтамасыз ететін интерфейс (әдетте веб). Бақылау тақтасында сүзгілер, көрсетілген көрсеткіштерді таңдау мүмкіндігі және т.б. болуы мүмкін. Интерфейс пайдаланушылар үшін ең маңызды көрсеткіштерді анықтауға арналған. Бақылау тақтасы техникалық қолдау көрсету персоналына арналған ақпаратты да көрсете алады: сұраулар кезегі, маңызды қателер тізімі және жауапкершіліктің берілген аймағына тағайындалған инженер.
Ескерту (хабарландыру)
Қателер немесе сұрау кезегінің ұлғаюы себеп болуы мүмкін электрондық пошта немесе басқа тәсілдер арқылы адам алуға арналған хабарландырулар. Хабарландырулар келесідей жіктеледі: билеттер, электрондық пошта ескертулері және жедел хабар алмасу хабарлары.
Түбірлі себеп
Түзетілгеннен кейін қайталанбауы тиіс бағдарламалық құрал ақауы немесе адам қатесі. Мәселе бірнеше негізгі себептерге байланысты болуы мүмкін: процесті автоматтандырудың жеткіліксіздігі, бағдарламалық құралдың ақаулығы, қолданбалы логиканың жеткіліксіз өңделуі. Бұл факторлардың әрқайсысы негізгі себеп болуы мүмкін және олардың әрқайсысын жою керек.
Түйін және машина (түйін және машина)
Физикалық серверде, виртуалды машинада немесе контейнерде іске қосылған қолданбаның бір данасына сілтеме жасау үшін ауыстырылатын терминдер. Бір құрылғы бірнеше қызметті орналастыра алады. Қызметтер болуы мүмкін:
- бір-бірімен байланысты: мысалы, кэштеу сервері және веб-сервер;
- бір аппараттық құралдағы байланыссыз қызметтер: мысалы, код репозиторийі және конфигурация жүйесіне арналған шебер, мысалы немесе .
Басыңыз
Бағдарламалық құрал конфигурациясындағы кез келген өзгеріс.
Мониторинг не үшін қажет?
Қолданбаларды бақылаудың бірнеше себептері бар:
Ұзақ мерзімді тенденцияларды талдау
Мәліметтер қоры қаншалықты үлкен және ол қаншалықты жылдам өсуде? Пайдаланушылардың күнделікті саны қалай өзгереді?
Өнімділікті салыстыру
Ajax DB 2.72-пен салыстырғанда Acme Bucket of Bytes 3.14 сұраулары жылдамырақ па? Қосымша түйін пайда болғаннан кейін сұраулар қаншалықты жақсы кэштеледі? Өткен аптамен салыстырғанда сайт баяу жұмыс істеп жатыр ма?
Ескерту (хабарландырулар)
Бірдеңе бұзылған және оны біреу жөндеуі керек. Немесе жақын арада бірдеңе бұзылады және біреу оны тез арада тексеруі керек.
Бақылау тақталарын құру
Бақылау тақталары негізгі сұрақтарға жауап беруі және бір нәрсені қамтуы керек — кешігулер (кідіріс), трафик (трафик), қателер (қателіктер) және жүктеме мөлшері (қанықтыру).
Ретроспективті талдау жүргізу (отладка)
Сұрауды өңдеу кідірісі артты, бірақ сол уақытта тағы не болды?
Бақылау жүйелері іскерлік барлау жүйелері үшін деректер көзі ретінде және қауіпсіздік инциденттерін талдауды жеңілдету үшін пайдалы. Бұл кітап ҒӨБ тәжірибесі бар инженерлік салаларға бағытталғандықтан, біз мұнда бақылау әдістерін талқыламаймыз.
Бақылау және ескертулер жүйеге оның қашан бұзылғанын немесе бұзылғалы тұрғанын хабарлауға мүмкіндік береді. Жүйе өзін автоматты түрде жөндей алмаса, біз адамның ескертуді талдап, мәселенің әлі де белсенді екенін анықтап, оны шешіп, негізгі себебін анықтауын қалаймыз. Жүйе құрамдастарын тексермесеңіз, «бірдеңе біртүрлі болып көрінгені үшін» сіз ешқашан ескерту алмайсыз.
Хабарламаларды жүктеп алу - қызметкердің уақытын өте қымбат пайдалану. Егер қызметкер жұмыс істеп тұрса, ескерту жұмыс процесін үзеді. Егер қызметкер үйде болса, ескерту жеке уақытты және мүмкін ұйқыны үзеді. Ескертулер тым жиі пайда болғанда, қызметкерлер оларды қарап шығып, кейінге қалдырады немесе кіріс ескертулерді елемейді. Кейде олар шу оқиғаларымен бүркемеленетін нақты ескертуді елемейді. Қызмет көрсету үзілістері ұзақ уақытқа созылуы мүмкін, себебі шу оқиғалары ақаулықты тез диагностикалауға және түзетуге кедергі жасайды. Тиімді ескерту жүйелерінде сигнал-шуыл арақатынасы жақсы.
Мониторинг жүйесіне негізделген күтулерді орнату
Күрделі қолданба үшін бақылауды орнатудың өзі күрделі инженерлік тапсырма болып табылады. Жинау, көрсету және ескерту құралдарының елеулі инфрақұрылымына қарамастан, 10-12 мүшеден тұратын Google SRE тобы әдетте негізгі мақсаты мониторинг жүйелерін құру және қолдау болып табылатын бір немесе екі адамды қамтиды. Мониторинг инфрақұрылымын біріктіріп, орталықтандырғандықтан, бұл сан уақыт өте азайды, бірақ әрбір SRE тобында әдетте тек бақылауға арналған кемінде бір адам болады. Мониторинг жүйесінің бақылау тақталарын қарау өте қызықты болғанымен, SRE командалары ақауларды бақылау үшін біреудің экранға қарауын талап ететін жағдайлардан мұқият аулақ болатындығын айтуымыз керек.
Тұтастай алғанда, Google оңтайлы фактілерді талдау құралдарымен қарапайым және жылдам бақылау жүйелеріне көшті. Біз табалдырықтарды болжауға тырысатын немесе негізгі себепті автоматты түрде анықтайтын «сиқырлы» жүйелерден аулақ боламыз. Түпкі пайдаланушы сұрауларында күтпеген мазмұнды анықтайтын сенсорлар жалғыз қарсы мысал болып табылады; Бұл сенсорлар қарапайым болғанша, олар елеулі ауытқулардың себептерін тез анықтай алады. Сыйымдылықты жоспарлау немесе трафикті болжау сияқты бақылау деректерін пайдаланудың басқа пішімдері күрделірек. Төмен іріктеу жылдамдығымен (сағат немесе күн) өте ұзақ уақыт кезеңінде (айлар немесе жылдар) бақылау ұзақ мерзімді тенденцияны анықтайды.
Google SRE командасы күрделі тәуелділік иерархияларымен аралас табысқа ие болды. Біз «егер дерекқордың баяу екенін білсем, дерекқордың баяу жұмыс істейтіні туралы ескерту аламын, әйтпесе сайт баяу екендігі туралы ескерту аламын» сияқты ережелерді сирек қолданамыз. Тәуелділікке негізделген ережелер әдетте деректер орталығына пайдаланушы трафигін сүзу жүйесі сияқты жүйенің өзгермейтін бөліктеріне сілтеме жасайды. Мысалы, «егер деректер орталығына трафикті сүзу конфигурацияланса, пайдаланушы сұрауларын өңдеудегі кешігулер туралы маған ескертпеңіз» - бұл деректер орталығынан ескертулерге арналған жалпы ереже. Google-дағы бірнеше командалар күрделі тәуелділік иерархияларын қолдайды, себебі біздің инфрақұрылымда үздіксіз рефакторингтің тұрақты жылдамдығы бар.
Осы тарауда сипатталған кейбір идеялар әлі де өзекті: әсіресе үнемі өзгеретін жүйелерде симптомнан негізгі себепке жылдамырақ өту мүмкіндігі әрқашан бар. Сондықтан, бұл тарауда мониторинг жүйелерінің кейбір мақсаттары және сол мақсаттарға жету жолдары көрсетілгенімен, мониторинг жүйелерінің командадағы барлық адамдар үшін қарапайым және түсінікті болуы маңызды.
Сол сияқты, шу деңгейін төмен және сигнал деңгейлерін жоғары ұстау үшін ескертілген активтерді бақылау тәсілдері өте қарапайым және сенімді болуы керек. Адамдарға ескерту жасайтын ережелер түсінуге оңай және нақты мәселені ұсынуы керек.
Себептерге қарсы белгілер
Сіздің бақылау жүйеңіз екі сұраққа жауап беруі керек: «не бұзылды» және «неліктен бұзылды».
«Не бұзылды» симптом туралы, ал «неліктен бұзылды» себебі туралы айтады. Төмендегі кестеде мұндай қосылыстардың мысалдары көрсетілген.
Белгі
Себеп
HTTP қатесі 500 немесе 404 алынуда
Дерекқор серверлері қосылымдарды қабылдамайды
Баяу сервер жауаптары
Жоғары процессорды пайдалану немесе зақымдалған Ethernet кабелі
Антарктидадағы пайдаланушылар мысықтардың GIF суреттерін алмайды
CDN ғалымдар мен мысықтарды жек көреді, сондықтан кейбір IP мекенжайлары қара тізімге енгізілді
Жеке мазмұн барлық жерден қолжетімді болды
Жаңа бағдарламалық құралдың шығарылымы брандмауэрді барлық ACL-ді ұмытып, барлығына кіруге мүмкіндік берді
«Не» және «неге» максималды сигнал және ең аз шу бар жақсы бақылау жүйесін құрудың ең маңызды құрылыс блоктарының кейбірі болып табылады.
Қара жәшік және Ақ жәшік
Біз ауқымды White-box мониторингін маңызды көрсеткіштер үшін қарапайым Black-box мониторингімен біріктіреміз. Қара жәшікті Ақ жәшікпен салыстырудың ең оңай жолы - қара жәшік симптомдарға бағытталған және белсенді бақылаудан гөрі реактивті: «жүйе қазір дұрыс жұмыс істемейді». Ақ жәшік жүйелердің ішкі тексеру мүмкіндіктеріне байланысты: оқиғалар журналдары немесе веб-серверлер. Осылайша, White-box күтілетін мәселелерді, сұрауды қайта жіберу сияқты көрінетін ақауларды және т.б. анықтауға мүмкіндік береді.
Көп қабатты жүйеде бір инженердің жауапкершілік аймағындағы симптом басқа инженердің жауапкершілік аймағындағы симптом екенін ескеріңіз. Мысалы, дерекқордың өнімділігі төмендеді. Дерекқорды баяу оқу - оларды анықтайтын SRE дерекқорының симптомы. Дегенмен, баяу веб-сайтты бақылайтын алдыңғы қатарлы SRE үшін бірдей баяу дерекқорды оқудың себебі - баяу дерекқор. Сондықтан ақ жәшік мониторингі оның қаншалықты ауқымды болуына байланысты кейде симптомға, кейде себепке бағытталған.
Түзету үшін телеметрияны жинаған кезде, White-box мониторингі қажет. Егер веб-серверлер дерекқор сұрауларына баяу жауап берсе, веб-сервердің дерекқормен қаншалықты жылдам байланысатынын және оның қаншалықты жылдам жауап беретінін білу керек. Әйтпесе, баяу дерекқор сервері мен веб-сервер мен дерекқор арасындағы желі мәселесін ажырата алмайсыз.
Ескертулерді жіберу кезінде қара жәшік мониторингінің басты артықшылығы бар: мәселе нақты белгілерге әкеліп соқтырған кезде сіз алушыға хабарландыруды қосасыз. Екінші жағынан, әлі туындамаған, бірақ жақын арада болатын Black-box мәселесі үшін мониторинг пайдасыз.
Төрт алтын сигнал
Бақылаудың төрт алтын сигналы: кідіріс, трафик, қателер және қанықтылық. Егер сіз тек төрт пайдаланушы жүйесінің көрсеткішін өлшей алсаңыз, осы төртеуіне назар аударыңыз.
Кешіктірілді
Өтінішті өңдеуге қажетті уақыт. Сәтті және сәтсіз сұраулардың кешігуін ажырату маңызды. Мысалы, дерекқорға немесе басқа серверге қосылудың жоғалуынан туындаған HTTP 500 қатесін өте жылдам диагностикалауға болады, алайда HTTP 500 қатесі сәтсіз сұрауды көрсетуі мүмкін. 500 қатенің жалпы кідіріске әсерін анықтау қате тұжырымдарға әкелуі мүмкін. Екінші жағынан, баяу қате - бұл тіпті жылдам қате! Сондықтан қателерді жай ғана сүзгіден өткізбей, қателердің кешігуін бақылау маңызды.
қозғалыс
Жүйеге сұраулар саны жоғары деңгейлі жүйелік көрсеткіштермен өлшенеді. Веб-қызмет үшін бұл өлшем әдетте сұраулардың сипатына (мысалы, статикалық немесе динамикалық мазмұн) бөлінген секундына HTTP сұрауларының санын көрсетеді. Дыбыс ағыны жүйесі үшін бұл өлшем желілік енгізу/шығару жылдамдығына немесе бір уақыттағы сеанстар санына назар аударуы мүмкін. Кілт-мәнді сақтау жүйесі үшін бұл өлшем транзакциялар немесе секундына іздеу нәтижелері болуы мүмкін.
Қателер
Бұл анық (мысалы, HTTP 500), жасырын (мысалы, HTTP 200, бірақ жарамсыз мазмұнмен біріктірілген) немесе саясат (мысалы, «Жауапты бір секундта жазып алсаңыз, кез келген секунд қате») болып табылатын сәтсіз сұраулардың жылдамдығы. HTTP жауап кодтары барлық сәтсіздік жағдайларын көрсету үшін жеткіліксіз болса, ішінара сәтсіздікті анықтау үшін қосымша (ішкі) протоколдар қажет болуы мүмкін. Барлық осындай сәтсіз сұрауларды бақылау ақпараттандырмауы мүмкін, бірақ жүйелік сынақтар қате мазмұнды өңдеп жатқаныңызды анықтауға көмектеседі.
Қанықтылық
Көрсеткіш қызметіңіздің қаншалықты қарқынды пайдаланылғанын көрсетеді. Бұл ең шектеулі ресурстарды анықтайтын жүйелік бақылау шарасы (мысалы, жады шектеулі жүйеде жадты көрсетеді, енгізу/шығару шектеулі жүйеде енгізу/шығару санын көрсетеді). Көптеген жүйелер 100% пайдалану деңгейіне жетпей өнімділікті төмендететінін ескеріңіз, сондықтан пайдалану мақсатына ие болу маңызды.
Күрделі жүйелерде қанықтылықты жоғары деңгейдегі жүктеме өлшемдерімен толықтыруға болады: сіздің қызметіңіз екі еселенген трафикті дұрыс өңдей ала ма, тек 10%-ға көп трафикті өңдей ала ма немесе қазіргіден де аз трафикті өңдей ала ма? Сұрау күрделілігін өзгертетін параметрлері жоқ (мысалы, «Маған ештеңе берме» немесе «Маған бірегей жалғыз монотонды бүтін сан керек») конфигурацияны сирек өзгертетін қарапайым қызметтер үшін статикалық жүктеме сынақ мәні барабар болуы мүмкін. Дегенмен, алдыңғы параграфта талқыланғандай, қызметтердің көпшілігі белгілі жоғарғы шекарасы бар орталық процессорды пайдалану немесе желінің өткізу қабілеті сияқты жанама сигналдарды пайдалануы керек. Кідірістің жоғарылауы көбінесе қанықтылықтың жетекші көрсеткіші болып табылады. Кішкентай терезеде 99-шы пайыздық жауап уақытын өлшеу (мысалы, бір минут) қанықтылықтың өте ерте сигналын бере алады.
Ақырында, қанықтылық алдағы қанықтылық туралы болжамдармен де байланысты, мысалы: «Дерекқор 4 сағат ішінде қатты дискіңізді толтыратын сияқты».
Егер сіз барлық төрт алтын сигналды өлшесеңіз және метриканың біреуінде ақаулық туындағанда (немесе қанықтылық жағдайында, жақын жерде ақаулық) сіз адамға ескертсеңіз, сіздің қызметіңіз азды-көпті бақылаумен қамтылады.
«Құйрық» (немесе аспаптар мен өнімділік) туралы алаңдаушылық
Бақылау жүйесін нөлден құру кезінде орташа мәндерге негізделген жүйені әзірлеуге азғырылады: орташа кідіріс, түйіндердің орташа CPU пайдалануы немесе дерекқордың орташа толықтығы. Соңғы екі мысалдың қауіптілігі анық: процессорлар мен деректер қоры өте күтпеген түрде жойылады. Бұл кешіктіруге де қатысты. Егер сіз секундына 100 сұраумен орташа кідіріспен 1000 мс веб-қызметті іске қоссаңыз, сұраулардың 1%-ы 5 секунд алуы мүмкін. Егер пайдаланушылар осындай бірнеше веб-қызметтерге тәуелді болса, бір сервердің 99-процентильі фронтендтің медианалық жауап беру уақыты болуы мүмкін.
Баяу орташа және өте баяу сұрауларды ажыратудың ең қарапайым жолы - нақты кідірістерден гөрі статистикада көрсетілген сұраулардың өлшемдерін жинау (көрсету үшін жақсы құрал гистограммалар болып табылады): қызмет 0 мс аралығында қанша сұрауға қызмет көрсетті және 10 мс, 10 мс және 30 мс, 30 мс және 100 мс, 100 мс және 300 мс және т.б.. Гистограмма шекараларын шамамен экспоненциалды түрде кеңейту (шамамен 3 коэффициентімен) таралуды визуализациялаудың қарапайым тәсілі жиі болып табылады. сұраулар.
Өлшеу үшін тиісті бөлшектер деңгейін таңдау
Жүйенің әртүрлі элементтері егжей-тегжейдің әртүрлі деңгейлерінде өлшенуі керек. Мысалы:
- Белгілі бір уақыт аралығында процессорды пайдалануды бақылау жоғары кідірістерге әкелетін ұзақ мерзімді өсулерді көрсетпейді.
- Екінші жағынан, жылына 9 сағаттан аспайтын үзіліс уақытын (99,9% жылдық жұмыс уақыты) бағытталған веб-қызмет үшін HTTP 200 жауабын минутына бір немесе екі реттен жиі тексеру қажетсіз жиі болуы мүмкін.
- Сол сияқты, қатты дискідегі бос орынның 99,9% қолжетімділігін 1-2 минут сайын бір реттен жиі тексеру қажет емес шығар.
Өлшемдердің түйіршіктілігін қалай құрылымдайтыныңызға назар аударыңыз. CPU жүктемесін секундына бір рет жинау қызықты деректерді қамтамасыз етуі мүмкін, бірақ мұндай жиі өлшеулерді жинау, сақтау және талдау өте қымбат болуы мүмкін. Бақылау мақсатыңыз жоғары түйіршіктілікті қажет етсе және жоғары жауап беруді қажет етпесе, серверде метрика жинағын орнату және содан кейін сол көрсеткіштерді жинау және біріктіру үшін сыртқы жүйені орнату арқылы осы шығындарды азайтуға болады. Сіз істей аласыз ба:
- Әр секунд сайын CPU жүктемесін өлшеңіз.
- Мәліметтерді 5%-ға дейін азайтыңыз.
- Әр минут сайын көрсеткіштерді біріктіріңіз.
Бұл стратегия жоғары талдау және сақтау шығындарынсыз деректерді жоғары түйіршіктілікпен жинауға мүмкіндік береді.
Мүмкіндігінше қарапайым, бірақ қарапайым емес
Әртүрлі талаптардың бір-бірінің үстіне қойылуы өте күрделі бақылау жүйесіне әкелуі мүмкін. Мысалы, сіздің жүйеңізде келесі күрделі элементтер болуы мүмкін:
- Әр түрлі көрсеткіштердің барлық түрлері үшін әртүрлі пайыздық мөлшерлемелердегі сұрауды өңдеу кідірісіне арналған әртүрлі шектерге сәйкес ескертулер.
- Ықтимал себептерді анықтау және анықтау үшін қосымша код жазу.
- Мәселелердің ықтимал себептерінің әрқайсысы үшін қатысты бақылау тақталарын жасаңыз.
Ықтимал асқыну көздері ешқашан бітпейді. Барлық бағдарламалық жүйелер сияқты, бақылаудың күрделі болуы соншалық, ол нәзік болады және өзгерту мен қолдау қиын болады.
Сондықтан бақылау жүйеңізді мүмкіндігінше жеңілдету үшін жобалаңыз. Бақылауды таңдағанда, мыналарды есте сақтаңыз:
- Нақты оқиғаларды жиі ұстайтын ережелер мүмкіндігінше қарапайым, болжамды және сенімді болуы керек.
- Сирек орындалатын деректерді жинау, біріктіру және ескерту конфигурациясын (мысалы, кейбір SRE топтары үшін тоқсан сайынғыдан аз) алып тастау керек.
- Жиналған, бірақ кез келген алдын ала қарау бақылау тақтасында көрсетілмеген немесе кез келген ескерту арқылы пайдаланылған көрсеткіштер жоюға үміткерлер болып табылады.
Google-де ескертулермен және бақылау тақталарымен біріктірілген негізгі көрсеткіштерді жинау және біріктіру салыстырмалы түрде дербес жүйе ретінде жақсы жұмыс істейді (Google-дың бақылау жүйесі іс жүзінде бірнеше ішкі жүйелерге бөлінген, бірақ адамдар әдетте осы ішкі жүйелердің барлық аспектілері туралы біледі). Мониторингті күрделі жүйелерді тексерудің басқа әдістерімен біріктіру қызықты болуы мүмкін: егжей-тегжейлі жүйе профилін жасау, процесті жөндеу, ерекше жағдайлар немесе сәтсіздіктер туралы мәліметтерді бақылау, жүктеме сынағы, журналды жинау және талдау немесе трафикті тексеру. Бұл заттардың көпшілігінің негізгі мониторингпен ортақ жақтары болса да, оларды араластыру тым көп нәтижеге әкеледі және күрделі және нәзік жүйені жасайды. Бағдарламалық жасақтаманы әзірлеудің көптеген басқа аспектілері сияқты, түсінікті, қарапайым, еркін біріктірілген интеграция нүктелері бар әртүрлі жүйелерді қолдау ең жақсы стратегия болып табылады (мысалы, ұзақ уақыт бойы тұрақты болып қала алатын пішімдегі жинақталған деректерді алу үшін веб API пайдалану) ).
Принциптерді біріктіру
Осы тарауда талқыланған принциптерді Google SRE топтары мақұлдаған және ұстанатын бақылау және ескерту философиясына біріктіруге болады. Бұл бақылау философиясын ұстанған жөн, ескерту әдіснамасын жасау немесе қайта қарау үшін жақсы бастапқы нүкте болып табылады және ұйымыңыздың көлеміне немесе қызметтің немесе жүйенің күрделілігіне қарамастан, операциялық функцияңыздың дұрыс сұрақтарын қоюға көмектеседі.
Бақылау және ескерту ережелерін жасау кезінде келесі сұрақтарды қою жалған позитивтерді және қажетсіз ескертулерді болдырмауға көмектеседі:
- Бұл ереже шұғыл, әрекетке шақыратын және пайдаланушыға сөзсіз әсер ететін жүйенің басқаша анықталмайтын күйін анықтайды ма?
- Қауіпсіз екенін біле тұра, бұл ескертуді елемеу мүмкін бе? Бұл ескертуді қашан және неге елемеуге болады және бұл сценарийді қалай болдырмауға болады?
- Бұл ескерту пайдаланушыларға теріс әсер ететінін білдіре ме? Трафикті сүзу арқылы немесе ескертулерді сүзгілеу қажет сынақ жүйелерін пайдалану сияқты пайдаланушыларға теріс әсер етпейтін жағдайлар бар ма?
- Осы ескертуге жауап ретінде әрекет ете аламын ба? Бұл шаралар шұғыл ма, әлде таңға дейін күте ала ма? Әрекетті қауіпсіз автоматтандыруға бола ма? Бұл әрекет ұзақ мерзімді шешім бола ма, әлде қысқа мерзімді шешім бола ма?
- Кейбір адамдар осы мәселе бойынша бірнеше ескертулер алуда, сондықтан ескертулер санын азайтудың жолы бар ма?
Бұл сұрақтар ескертулер мен ескерту жүйелерінің негізгі философиясын көрсетеді:
- Ескерту келген сайын мен дереу әрекет етуім керек. Мен шаршағанша күніне бірнеше рет шұғыл әрекет ете аламын.
- Әрбір ескерту сәйкес болуы керек.
- Ескертуге әрбір жауап адамның араласуын талап етуі керек. Егер хабарландыру автоматты түрде өңделуі мүмкін болса, ол келмеуі керек.
- Ескертулер бұрын болмаған жаңа мәселе немесе оқиға туралы болуы керек.
Бұл тәсіл белгілі бір айырмашылықтарды бұлдыратады: ескерту алдыңғы төрт шартты қанағаттандырса, ескерту White-box немесе Black-Box бақылау жүйесінен жіберілгені маңызды емес. Бұл тәсіл белгілі бір айырмашылықтарды да күшейтеді: себептерге қарағанда симптомдарды анықтауға көбірек күш жұмсаған дұрыс; Себептерге келетін болсақ, сіз тек еріксіз себептер туралы алаңдауыңыз керек.
Ұзақ мерзімді мониторинг
Бүгінгі өнімділік орталарында мониторинг жүйелері бағдарламалық жасақтаманың архитектурасы, жұмыс жүктемесі сипаттамалары және өнімділік мақсаттары өзгеретін үнемі дамып отыратын өндіріс жүйесін бақылайды. Қазіргі уақытта автоматтандыру қиынға соғатын ескертулер әдеттегідей болуы мүмкін, тіпті шешуге тұрарлық. Осы кезде біреу проблеманың түпкі себептерін тауып, жоюы керек; егер мұндай ажыратымдылық мүмкін болмаса, ескертуге жауап беру толық автоматтандыруды қажет етеді.
Бақылау шешімдері ұзақ мерзімді мақсаттарды ескере отырып қабылдануы маңызды. Бүгін іске қосылған әрбір ескерту адамды ертең жүйені жақсартудан алшақтатады, сондықтан ұзақ мерзімді перспективада мониторинг жүйесін жақсарту үшін қажетті уақыт ішінде өнімді жүйенің қолжетімділігі немесе өнімділігі жиі төмендейді. Бұл құбылысты түсіндіру үшін екі мысалды қарастырайық.
Bigtable SRE: Шамадан тыс ескерту туралы әңгіме
Google-дың ішкі инфрақұрылымы әдетте қызмет көрсету деңгейіне (SLO) қатысты қамтамасыз етіледі және өлшенеді. Көптеген жылдар бұрын Bigtable қызметі SLO тірі клиентті имитациялайтын синтетикалық транзакцияның орташа өнімділігіне негізделген. Bigtable жүйесіндегі мәселелерге және жад стектің төменгі деңгейлеріне байланысты орташа өнімділік «үлкен» құйрықпен басқарылды: сұраулардың ең нашар 5% көбіне қалғандарына қарағанда айтарлықтай баяу болды.
Электрондық пошта хабарландырулары SLO шегіне жақындағанда жіберілді және SLO шегінен асып кеткенде хабаршы ескертулері жіберілді. Ескертулердің екі түрі де жиі жіберілді, бұл инженерлік уақыттың қолайсыз көлемін тұтынды: команда нақты сәйкес келетін бірнеше ескертулерді табу үшін ескертулерді сұрыптауға көп уақыт жұмсады. Біз пайдаланушыларға нақты әсер еткен мәселені жиі жіберіп алдық, себебі ескертулердің кейбірі ғана осы нақты мәселеге қатысты. Көптеген ескертулер инфрақұрылымдағы түсінікті мәселелерге байланысты шұғыл емес және стандартты түрде өңделген немесе мүлде өңделмеген.
Жағдайды түзету үшін команда үш бағытты ұстанды: Bigtable өнімділігін жақсарту үшін көп жұмыс жасай отырып, біз уақытша SLO мақсатымызды сұрауға жауап берудің кідірісі үшін 75-ші пайыздық көрсеткішке айналдырдық. Сондай-ақ біз электрондық пошта ескертулерін өшірдік, өйткені олардың саны сонша, диагностикалауға уақыт жұмсау мүмкін болмады.
Бұл стратегия бізге тыныс алу бөлмесіне тактикалық мәселелерді үнемі шешудің орнына Bigtable және сақтау стектің төменгі деңгейлеріндегі ұзақ мерзімді мәселелерді шешуге мүмкіндік берді. Инженерлер үнемі ескертулермен бомбаланбай-ақ жұмысты аяқтай алады. Сайып келгенде, ескертулерді өңдеуді уақытша кейінге қалдыру бізге қызметіміздің сапасын жақсартуға мүмкіндік берді.
Gmail: Болжауға болатын, адамның алгоритмдік жауаптары
Өзінің басында Gmail іздеу индексінің процесс бөліктерін топтастыруға арналған өзгертілген Workqueue процесін басқару жүйесінде құрылды. Жұмыс кезегі ұзаққа созылатын процестерге бейімделіп, кейіннен Gmail қызметіне қолданылды, бірақ бұлыңғыр жоспарлаушы кодындағы кейбір қателерді түзету өте қиын болды.
Ол кезде Gmail мониторингі жұмыс кезегі арқылы жеке тапсырмалардан бас тартылған кезде ескертулер іске қосылатын етіп құрылымдалған. Бұл тәсіл идеалды емес еді, өйткені сол кезде де Gmail мыңдаған тапсырмаларды орындады, олардың әрқайсысы біздің пайдаланушыларымыздың пайызының бір бөлігіне берілген. Біз Gmail пайдаланушыларына жақсы пайдаланушы тәжірибесін ұсынуға қатты алаңдадық, бірақ көптеген ескертулерді өңдеу мүмкін емес еді.
Бұл мәселені шешу үшін Gmail SRE пайдаланушыларға әсерін азайту үшін жоспарлаушыны мүмкіндігінше оңтайлы жөндеуге көмектесетін құрал жасады. Команда ұзақ мерзімді шешім табылғанға дейін проблеманы анықтаудан бастап түзетуге дейінгі бүкіл циклды жай ғана автоматтандыру керек пе деген сұрақты талқылады, бірақ кейбіреулер мұндай шешім мәселені шешуді кешіктіреді деп алаңдады.
Бұл шиеленіс командада жиі болды және көбінесе өзін-өзі тәрбиелеуге деген сенімсіздікті көрсетеді: кейбір топ мүшелері дұрыс түзетуге уақыт бергісі келсе, басқалары соңғы түзету ұмытылады және уақытша түзету мәңгілікке созылады деп алаңдайды. Бұл мәселе назар аударуды қажет етеді, себебі жағдайды тұрақты етудің орнына ақауларды уақытша түзету өте оңай. Менеджерлер мен техникалық қызметкерлер ұзақ мерзімді түзетулерді енгізуде, бастапқы «ауыру» басылғаннан кейін де ықтимал ұзақ мерзімді түзетулерді қолдауда және басымдық беруде маңызды рөл атқарады.
Тұрақты, қайталанатын ескертулер мен алгоритмдік жауаптар қызыл жалауша болуы керек. Сіздің командаңыздың бұл ескертулерді автоматтандыруды қаламауы команданың алгоритмдерге сене алатынына сенімсіздігін білдіреді. Бұл шешуді қажет ететін күрделі мәселе.
Ұзақ мерзімді кезеңде
Жалпы тақырып Bigtable және Gmail мысалдарын байланыстырады: қысқа мерзімді және ұзақ мерзімді қолжетімділік арасындағы бәсекелестік. Көбінесе күшті күш-жігер нәзік жүйеге жоғары қолжетімділікке қол жеткізуге көмектеседі, бірақ бұл жол әдетте қысқа мерзімді, команданың күйіп қалуына және сол батыр команданың аздаған мүшелеріне тәуелділікке толы.
Бақыланатын, қол жетімділіктің қысқа мерзімді қысқаруы жиі ауырады, бірақ жүйенің ұзақ мерзімді тұрақтылығы үшін стратегиялық маңызды. Әрбір ескертуді оқшауламай, ескерту көлемінің жалпы деңгейі өміршең командасы және қолайлы болжамы бар сау, дұрыс қол жетімді жүйеге әкелетінін ескеру маңызды. Біз ескерту жиілігі статистикасын (әдетте оқиға бір ауысымдағы оқиғалар ретінде көрсетіледі, онда оқиға бірнеше байланысты оқиғалардан тұруы мүмкін) тоқсан сайынғы есептерде басшылыққа беріледі, бұл шешім қабылдаушыларға ескерту жүйесінің жүктемесі мен жалпы топ денсаулығы туралы тұрақты көзқарасқа ие болуға мүмкіндік береді.
қорытынды
Салауатты бақылау және ескерту жолы қарапайым және түсінікті. Ол ескертулерді тудыратын мәселенің белгілеріне назар аударады және себебін бақылау ақауларды түзетуге көмекші ретінде қызмет етеді. Бақылау белгілері сіз басқаратын стекте неғұрлым жоғары болса, соғұрлым оңайырақ болады, дегенмен дерекқордың жүктемесі мен өнімділігін бақылау тікелей дерекқордың өзінде орындалуы керек. Электрондық пошта хабарландыруларының пайдалылығы өте шектеулі және оңай шуылға айналады; оның орнына электрондық пошта ескертулерін іске қосатын барлық ағымдағы мәселелерді бақылайтын бақылау тақтасын пайдалану керек. Бақылау тақтасын тарихи корреляцияларды талдау үшін оқиғалар журналымен жұптастыруға болады.
Ұзақ мерзімді перспективада бақылаудың жылдам диагнозды қолдайтынын қамтамасыз ету үшін мақсаттарды бейімдейтін белгілер мен жақын арада болатын нақты проблемалар туралы ескертулердің сәтті айналымына қол жеткізу қажет.
Аударманы соңына дейін оқығаныңыз үшін рахмет. Бақылау туралы менің телеграм каналыма жазылыңыз и .
Ақпарат көзі: www.habr.com