SRE (Site Reliability Engineering) е подход за осигуряване на наличност на уеб проекти. Смята се за рамка за DevOps и говори за това как да постигнете успех в прилагането на практиките на DevOps. Превод в тази статия Глави 6 Мониторинг на разпределени системи книги Инженеринг за надеждност на сайта от Google. Подготвих този превод сам и разчитах на собствения си опит в разбирането на процесите на мониторинг. В телеграм канала @monitorim_it и блог на Medium Публикувах и връзка към превода на глава 4 от същата книга относно целите на нивото на обслужване.

Превод по кат. Наслади се на четенето!

Екипите на SRE на Google имат основни принципи и най-добри практики за създаване на успешни системи за наблюдение и уведомяване. Тази глава предоставя насоки за проблемите, с които може да се сблъска посетителят на уеб страница и как да разреши проблемите, които правят уеб страниците трудни за показване.

дефинира

Няма единен речник, използван за обсъждане на теми, свързани с мониторинга. Дори в Google термините по-долу не се използват често, но ще изброим най-често срещаните тълкувания.

мониторинг

Събиране, обработка, агрегиране и показване на количествени данни в реално време за системата: брой заявки и типове заявки, брой грешки и типове грешки, време за обработка на заявки и време на работа на сървъра.

Мониторинг в бяла кутия

Мониторинг въз основа на показатели, показвани от вътрешни системни компоненти, включително регистрационни файлове, показатели за профилиране на виртуална машина на Java или показатели за обработка на HTTP, които генерират вътрешна статистика.

Мониторинг в черна кутия

Тестване на поведението на приложението от гледна точка на потребителя.

Табло

Интерфейс (обикновено уеб), който предоставя общ преглед на ключови показатели за здравето на услугите. Таблото за управление може да има филтри, възможност за избор на показаните индикатори и т.н. Интерфейсът е предназначен да идентифицира индикаторите, които са най-важни за потребителите. Таблото може също така да показва информация за персонала за техническа поддръжка: опашка от заявки, списък с грешки с висок приоритет и назначен инженер за дадена област на отговорност.

Предупреждение (известие)

Известия, предназначени да бъдат получени от лице по имейл или по друг начин, което може да бъде предизвикано от грешки или увеличаване на опашката за заявки. Известията се класифицират като: билети, имейл предупреждения и незабавни съобщения.

Първопричина

Софтуерен дефект или човешка грешка, която веднъж коригирана, не трябва да се появява отново. Проблемът може да има няколко основни причини: недостатъчна автоматизация на процеса, софтуерен дефект, недостатъчна разработка на логиката на приложението. Всеки от тези фактори може да е основната причина и всеки от тях трябва да бъде елиминиран.

Възел и машина (възел и машина)

Взаимозаменяеми термини за обозначаване на едно копие на работещо приложение на физически сървър, виртуална машина или контейнер. Една машина може да хоства няколко услуги. Услугите могат да бъдат:

• свързани един с друг: например сървър за кеширане и уеб сървър;
• несвързани услуги на един хардуерен елемент: например хранилище на кодове и съветник за конфигурационна система, като напр. Кукла на конци или Главният ни готвач.

Тласък

Всяка промяна в софтуерната конфигурация.

Защо е необходим мониторинг?

Има няколко причини, поради които приложенията трябва да бъдат наблюдавани:

Анализ на дългосрочни тенденции

Колко голяма е базата данни и колко бързо расте? Как се променя дневният брой потребители?

Сравнение на производителността

Заявките по-бързи ли са на Acme Bucket of Bytes 2.72 в сравнение с Ajax DB 3.14? Колко по-добре се кешират заявките след появата на допълнителен възел? Сайтът работи ли по-бавно в сравнение с миналата седмица?

Предупреждаване (известия)

Нещо е счупено и някой трябва да го поправи. Или нещо скоро ще се счупи и някой трябва скоро да го провери.

Създаване на табла за управление

Таблата за управление трябва да отговарят на основни въпроси и да включват нещо от "4 златни сигнала" — закъснения (закъснение), трафик (трафик), грешки (грешки) и размер на зареждането (насищане).

Провеждане на ретроспективен анализ (дебъгване)

Забавянето на обработката на заявката се е увеличило, но какво друго се е случило по същото време?
Системите за наблюдение са полезни като източник на данни за системите за бизнес разузнаване и за улесняване на анализа на инциденти със сигурността. Тъй като тази книга се фокусира върху инженерни области, в които SRE имат опит, тук няма да обсъждаме техники за наблюдение.

Мониторингът и предупрежденията позволяват на системата да ви каже, когато е повредена или е на път да се повреди. Когато системата не може автоматично да се поправи, ние искаме човек да анализира предупреждението, да определи дали проблемът все още е активен, да го разреши и да определи първопричината. Ако не проверявате системните компоненти, никога няма да получите предупреждение просто защото „нещо изглежда малко странно“.

Натоварването на човек с известия е доста скъпо използване на времето на служителя. Ако служителят работи, сигналът прекъсва работния процес. Ако служителят е вкъщи, сигналът прекъсва личното време и евентуално съня. Когато сигналите се появяват твърде често, служителите ги преглеждат набързо, отлагат ги или игнорират входящите сигнали. От време на време те игнорират истинската тревога, която е маскирана от шумови събития. Прекъсванията на услугата могат да продължат за дълги периоди от време, тъй като шумовите събития пречат на бързото диагностициране и коригиране на проблема. Ефективните системи за предупреждение имат добро съотношение сигнал/шум.

Задаване на разумни очаквания за системата за мониторинг

Настройването на мониторинг за сложно приложение само по себе си е сложна инженерна задача. Дори със значителна инфраструктура от инструменти за събиране, показване и известяване, екипът на Google SRE от 10–12 членове обикновено включва един или двама души, чиято основна цел е да изграждат и поддържат системи за наблюдение. Този брой е намалял с течение на времето, тъй като консолидираме и централизираме инфраструктурата за мониторинг, но всеки SRE екип обикновено има поне един човек, посветен единствено на мониторинга. Трябва да кажем, че докато таблата за управление на системата за наблюдение са доста интересни за разглеждане, екипите на SRE внимателно избягват ситуации, които изискват някой да гледа екрана, за да наблюдава проблемите.

Като цяло Google премина към прости и бързи системи за наблюдение с оптимални инструменти за последващ анализ. Ние избягваме „магически“ системи, които се опитват да предвидят прагове или автоматично да открият първопричината. Сензорите, които откриват нежелано съдържание в заявките на крайните потребители, са единственият контрапример; Докато тези сензори остават прости, те могат бързо да открият причините за сериозни аномалии. Други формати за използване на данни за мониторинг, като планиране на капацитета или прогнозиране на трафика, са по-сложни. Наблюдение за много дълъг период от време (месеци или години) при ниска честота на вземане на проби (часове или дни) ще разкрие дългосрочна тенденция.

Екипът на Google SRE имаше смесен успех със сложни йерархии на зависимости. Рядко използваме правила като „ако разбера, че базата данни е бавна, получавам предупреждение, че базата данни е бавна, в противен случай получавам предупреждение, че сайтът е бавен.“ Базираните на зависимости правила обикновено се отнасят до неизменни части от нашата система, като например системата за филтриране на потребителския трафик към центъра за данни. Например „ако филтрирането на трафика към центъра за данни е конфигурирано, не ме предупреждавай за закъснения при обработката на потребителски заявки“ е едно общо правило за предупреждения от центъра за данни. Малко екипи в Google поддържат сложни йерархии на зависимости, тъй като нашата инфраструктура има постоянна скорост на непрекъснато рефакторинг.

Някои от идеите, описани в тази глава, все още са актуални: винаги има възможност да се премине по-бързо от симптома към първопричината, особено в постоянно променящите се системи. Ето защо, въпреки че тази глава очертава някои цели за системите за мониторинг и как да се постигнат тези цели, важно е системите за мониторинг да са прости и разбираеми за всички в екипа.

По същия начин, за да се поддържат ниски нива на шум и високи нива на сигнала, подходите за наблюдение на алармени активи трябва да бъдат много прости и надеждни. Правилата, които генерират предупреждения за хората, трябва да са лесни за разбиране и да представляват ясен проблем.

Симптоми срещу причини

Вашата система за наблюдение трябва да отговори на два въпроса: „какво се счупи“ и „защо се счупи“.
„Какво се счупи“ говори за симптома, а „защо се счупи“ говори за причината. Таблицата по-долу показва примери за такива връзки.

Симптом
Причина

Получаване на HTTP грешка 500 или 404
Сървърите на бази данни отхвърлят връзки

Бавни отговори на сървъра
Високо натоварване на процесора или повреден Ethernet кабел

Потребителите в Антарктика не получават GIF файлове с котки
Вашият CDN мрази учени и котки, така че някои IP адреси в крайна сметка бяха включени в черния списък

Частното съдържание стана достъпно отвсякъде
Пускането на нова версия на софтуера накара защитната стена да забрави всички ACL и да пусне всички

„Какво“ и „защо“ са едни от най-важните градивни елементи за създаване на добра система за наблюдение с максимален сигнал и минимален шум.

Черна кутия срещу бяла кутия

Ние съчетаваме обширно наблюдение на бяла кутия със скромен мониторинг на черна кутия за критични показатели. Най-лесният начин да сравните Black-box с White-box е, че Black-box е фокусиран върху симптомите и е по-скоро реактивен, отколкото проактивен мониторинг: „системата не работи правилно в момента“. Бялата кутия зависи от възможностите за вътрешна проверка на системите: регистрационни файлове на събития или уеб сървъри. Така White-box ви позволява да откриете предстоящи проблеми, грешки, които изглеждат като повторно предаване на заявка и т.н.

Имайте предвид, че в многослойна система, симптом в зоната на отговорност на един инженер е симптом в зоната на отговорност на друг инженер. Например производителността на базата данни е намаляла. Бавното четене на база данни е симптом на базата данни SRE, която ги открива. Въпреки това, за преден SRE, наблюдаващ бавен уебсайт, причината за същото бавно четене на база данни е бавна база данни. Следователно мониторингът с бяла кутия понякога е фокусиран върху симптомите, а понякога върху причината, в зависимост от това колко обширно е то.

Когато се събират телеметрични данни за отстраняване на грешки, е необходимо наблюдение на бялата кутия. Ако уеб сървърите реагират бавно на заявки към базата данни, трябва да знаете колко бързо уеб сървърът комуникира с базата данни и колко бързо отговаря. В противен случай няма да можете да направите разлика между бавен сървър на база данни и мрежов проблем между уеб сървъра и базата данни.

Мониторингът в черна кутия има ключово предимство при изпращане на предупреждения: задействате известието до получателя, когато проблемът вече е довел до реални симптоми. От друга страна, наблюдението е безполезно за проблем с черната кутия, който все още не е възникнал, но е неизбежен.

Четири златни сигнала

Четирите златни мониторингови сигнала са латентност, трафик, грешки и насищане. Ако можете да измерите само четири потребителски системни показателя, съсредоточете се върху тези четири.

закъснение

Времето, необходимо за обработка на заявката. Важно е да се прави разлика между забавянето на успешните и неуспешните заявки. Например грешка HTTP 500, причинена от загуба на връзка с база данни или друг бекенд, може да бъде диагностицирана много бързо, но грешка HTTP 500 може да означава неуспешна заявка. Определянето на влиянието на грешка 500 върху общото забавяне може да доведе до погрешни заключения. От друга страна, бавната грешка е дори бърза грешка! Следователно е важно да наблюдавате латентността на грешката, а не просто да филтрирате грешките.

трафик

Броят на заявките към вашата система се измерва в системни показатели на високо ниво. За уеб услуга това измерване обикновено представлява броя HTTP заявки за секунда, разделен на естеството на заявките (например статично или динамично съдържание). За система за аудио стрийминг, това измерване може да се съсредоточи върху мрежовата I/O скорост или броя на едновременните сесии. За система за съхранение на ключ-стойност това измерване може да бъде транзакции или резултати от търсене в секунда.

Грешки

Това е процентът на неуспешни заявки, които са изрични (напр. HTTP 500), неявни (напр. HTTP 200, но комбинирани с невалидно съдържание) или правила (напр. „Ако сте уловили отговор за една секунда, всяка една секунда е грешка“). Ако HTTP кодовете за отговор не са достатъчни, за да изразят всички условия на повреда, може да са необходими вторични (вътрешни) протоколи за откриване на частична повреда. Мониторингът на всички такива неуспешни заявки може да не е информативен, докато системните тестове от край до край ще ви помогнат да откриете, че обработвате неправилно съдържание.

Наситеност

Показателят показва колко интензивно се използва вашата услуга. Това е мярка за наблюдение на системата, която идентифицира ресурсите, които са най-ограничени (например, на система с ограничена памет, показва паметта, на система с ограничения на I/O, показва броя на I/O). Имайте предвид, че много системи влошават производителността, преди да достигнат 100% използване, така че е важно да имате цел за използване.

В сложни системи насищането може да бъде допълнено от измервания на натоварването на по-високо ниво: може ли вашата услуга да обработва правилно двоен трафик, да обработва само 10% повече трафик или да обработва дори по-малко трафик, отколкото в момента? За прости услуги, които нямат параметри, които променят сложността на заявката (например „Не ми давайте нищо“ или „Имам нужда от уникално единично монотонно цяло число“), които рядко променят конфигурацията, стойността на теста за статично натоварване може да е подходяща. Въпреки това, както беше обсъдено в предишния параграф, повечето услуги трябва да използват индиректни сигнали като използване на процесора или честотна лента на мрежата, които имат известна горна граница. Увеличаването на латентността често е водещ индикатор за насищане. Измерването на времето за реакция на 99-ия персентил в малък прозорец (напр. една минута) може да осигури много ранен сигнал за насищане.

И накрая, насищането се свързва и с прогнози за предстоящо насищане, например: „Изглежда, че вашата база данни ще запълни твърдия ви диск след 4 часа.“

Ако измервате и четирите златни сигнала и когато има проблем с един от показателите (или, в случай на насищане, почти проблем), предупредите човек, вашата услуга ще бъде повече или по-малко покрита от мониторинг.

Притеснения за "опашката" (или инструментариум и изпълнение)

Когато създавате система за мониторинг от нулата, има изкушение да се разработи система, базирана на средни стойности: средна латентност, средно използване на процесора на възлите или средна пълнота на базата данни. Опасността от последните два примера е очевидна: процесорите и базите данни се изхвърлят по много непредвидим начин. Същото важи и за забавянето. Ако изпълнявате уеб услуга със средно забавяне от 100 ms с 1000 заявки в секунда, 1% от заявките може да отнеме 5 секунди. Ако потребителите зависят от множество такива уеб услуги, 99-ият процентил на един бекенд може лесно да се превърне в средното време за реакция на фронтенда.

Най-простият начин за разграничаване между бавната средна и много бавната опашка на заявките е да се съберат измервания на заявките, изразени в статистика (добър инструмент за показване са хистограми), а не действителни закъснения: колко заявки е обслужила услугата, които са отнели между 0 ms и 10 ms, между 10 ms и 30 ms, между 30 ms и 100 ms, между 100 ms и 300 ms и т.н. Разширяването на границите на хистограмата приблизително експоненциално (с приблизителен фактор 3) често е лесен начин за визуализиране на разпределението от искания.

Избор на подходящо ниво на детайлност за измервания

Различните елементи на системата трябва да се измерват на различни нива на детайлност. Например:

• Наблюдението на използването на процесора за определен период от време няма да покаже дългосрочни скокове, които водят до големи закъснения.
• От друга страна, за уеб услуга, насочена към не повече от 9 часа престой на година (99,9% годишен ъптайм), проверката за HTTP 200 отговор повече от веднъж или два пъти в минута вероятно ще бъде ненужно честа.
• По същия начин вероятно не е необходимо да се проверява пространството на твърдия диск за 99,9% наличност повече от веднъж на всеки 1-2 минути.

Внимавайте как структурирате детайлността на вашите измервания. Събирането на натоварването на процесора веднъж в секунда може да предостави интересни данни, но такива чести измервания могат да бъдат много скъпи за събиране, съхраняване и анализиране. Ако вашата цел за наблюдение изисква висока детайлност и не изисква висока бързина на реакция, можете да намалите тези разходи, като настроите събиране на показатели на сървъра и след това настроите външна система за събиране и обобщаване на тези показатели. Можеш ли:

1. Измервайте натоварването на процесора всяка секунда.
2. Намаляване на детайлите до 5%.
3. Обобщавайте показатели всяка минута.

Тази стратегия ще ви позволи да събирате данни с висока детайлност, без да налагате големи разходи за анализ и съхранение.

Възможно най-просто, но не и по-просто

Наслагването на различни изисквания едно върху друго може да доведе до много сложна система за наблюдение. Например, вашата система може да има следните усложняващи елементи:

• Сигнали според различни прагове за латентност при обработка на заявки, в различни процентили, за всички видове различни индикатори.
• Писане на допълнителен код за откриване и идентифициране на възможни причини.
• Създайте свързани табла за управление за всяка от възможните причини за проблеми.

Източниците на потенциални усложнения никога не свършват. Както всички софтуерни системи, мониторингът може да стане толкова сложен, че да стане крехък и труден за промяна и поддръжка.

Затова проектирайте вашата система за наблюдение, за да я опростите възможно най-много. Когато избирате какво да проследявате, имайте предвид следното:

• Правилата, които най-често улавят реални инциденти, трябва да бъдат възможно най-прости, предвидими и надеждни.
• Конфигурация за събиране на данни, агрегиране и известяване, която се извършва рядко (например по-малко от тримесечие за някои SRE екипи), трябва да бъде премахната.
• Показатели, които се събират, но не се показват в нито едно табло за визуализация или се използват от който и да е сигнал, са кандидати за изтриване.

В Google събирането и агрегирането на основни показатели, съчетани с предупреждения и табла за управление, работят добре като сравнително самостоятелна система (системата за наблюдение на Google всъщност е разделена на няколко подсистеми, но хората обикновено са наясно с всички аспекти на тези подсистеми). Може да е изкушаващо да комбинирате наблюдението с други техники за изследване на сложни системи: детайлно профилиране на системата, отстраняване на грешки в процеса, проследяване на подробности за изключения или неуспехи, тестване на натоварването, събиране и анализ на регистрационни файлове или проверка на трафика. Докато повечето от тези неща имат общи черти с основния мониторинг, смесването им ще доведе до твърде много резултати и ще създаде сложна и крехка система. Както при много други аспекти на разработката на софтуер, поддържането на различни системи с ясни, прости, слабо свързани точки на интеграция е най-добрата стратегия (например използване на уеб API за извличане на обобщени данни във формат, който може да остане последователен за дълъг период от време ).

Обвързване на принципите

Принципите, обсъдени в тази глава, могат да бъдат комбинирани във философия за наблюдение и предупреждение, която е одобрена и следвана от екипите на Google SRE. Придържането към тази философия за наблюдение е желателно, е добра отправна точка за създаване или преразглеждане на вашата методология за предупреждение и може да ви помогне да зададете правилните въпроси за вашата оперативна функция, независимо от размера на вашата организация или сложността на услугата или системата.

Когато създавате правила за наблюдение и предупреждение, задаването на следните въпроси може да ви помогне да избегнете фалшиви положителни резултати и ненужни предупреждения:

• Това правило открива ли иначе неоткриваемо състояние на системата, което е спешно, призовава за действие и неизбежно засяга потребителя?
• Мога ли да пренебрегна това предупреждение, знаейки, че е доброкачествено? Кога и защо мога да пренебрегна това предупреждение и как мога да избегна този сценарий?
• Това предупреждение означава ли, че потребителите са засегнати отрицателно? Има ли ситуации, при които потребителите не са засегнати отрицателно, като например чрез филтриране на трафика или при използване на тестови системи, за които сигналите трябва да бъдат филтрирани?
• Мога ли да предприема действия в отговор на този сигнал? Тези мерки спешни ли са или могат да изчакат до сутринта? Може ли едно действие да бъде безопасно автоматизирано? Ще бъде ли това действие дългосрочно решение или краткосрочно решение?
• Някои хора получават множество сигнали за този проблем, така че има ли начин да се намали броят на сигналите?

Тези въпроси отразяват основната философия на системите за сигнали и предупреждения:

• Всеки път, когато постъпи сигнал, трябва да реагирам незабавно. Мога да реагирам спешно няколко пъти на ден, преди да се изморя.
• Всеки сигнал трябва да е подходящ.
• Всеки отговор на сигнал трябва да изисква човешка намеса. Ако известието може да се обработи автоматично, то не би трябвало да пристигне.
• Сигналите трябва да са за нов проблем или събитие, което не е съществувало преди.

Този подход заличава определени разлики: ако предупреждението отговаря на предходните четири условия, няма значение дали предупреждението е изпратено от система за наблюдение на бяла кутия или черна кутия. Този подход също така засилва някои различия: по-добре е да се отделят много повече усилия за идентифициране на симптомите, отколкото върху причините; когато става дума за причини, трябва да се тревожите само за неизбежните причини.

Дългосрочно наблюдение

В днешните производствени среди системите за мониторинг наблюдават непрекъснато развиваща се производствена система с променяща се софтуерна архитектура, характеристики на работното натоварване и цели за производителност. Сигнали, които понастоящем са трудни за автоматизиране, може да станат обичайни, може би дори си струва да се обърне внимание. В този момент някой трябва да открие и отстрани първопричините за проблема; ако такова решение не е възможно, отговорът на сигнала изисква пълна автоматизация.

Важно е решенията за наблюдение да се вземат с оглед на дългосрочните цели. Всяко предупреждение, което се изпълнява днес, отвлича вниманието на човек от подобряването на системата утре, така че често има намаляване на наличността или производителността на продуктивна система за времето, необходимо за подобряване на системата за наблюдение в дългосрочен план. Нека да разгледаме два примера, за да илюстрираме това явление.

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: конкуренцията между краткосрочна и дългосрочна наличност. Често големите усилия могат да помогнат на една крехка система да постигне висока достъпност, но този път обикновено е краткотраен, изпълнен с прегаряне на екипа и зависимост от малък брой членове на същия този героичен екип.

Контролираното, краткосрочно намаляване на наличността често е болезнено, но стратегически важно за дългосрочната стабилност на системата. Важно е да не разглеждате всеки сигнал изолирано, а да прецените дали общото ниво на обема на сигналите води до здрава, правилно достъпна система с жизнеспособен екип и благоприятна прогноза. Ние анализираме статистическите данни за честотата на предупрежденията (обикновено изразени като инциденти на смяна, където един инцидент може да се състои от множество свързани инциденти) в тримесечни доклади до ръководството, което позволява на вземащите решения да имат постоянен поглед върху натоварването на системата за предупреждение и цялостното здраве на екипа.

Заключение

Пътят към здравословно наблюдение и предупреждение е прост и ясен. Той се фокусира върху симптомите на проблема, които предизвикват предупреждения, а наблюдението на причината служи като помощ при отстраняване на грешки при проблеми. Наблюдението на симптомите е по-лесно, колкото по-високо сте в стека, който контролирате, въпреки че наблюдението на натоварването и производителността на базата данни трябва да се извършва директно в самата база данни. Известията по имейл имат много ограничена полезност и са склонни лесно да се превърнат в шум; вместо това трябва да използвате табло за управление, което следи всички текущи проблеми, които задействат предупреждения по имейл. Таблото за управление може също да бъде сдвоено с регистър на събитията за анализиране на исторически корелации.

В дългосрочен план е необходимо да се постигне успешна ротация на сигнали за симптоми и предстоящи реални проблеми, като се адаптират целите, за да се гарантира, че мониторингът подпомага бързата диагностика.

Благодаря ви, че прочетохте превода до края. Абонирайте се за моя телеграм канал за мониторинг @monitorim_it и блог на Medium.

Източник: www.habr.com