Дали мониторингот е мртов? — Да живее мониторингот

Од 2008 година, нашата компанија првенствено се занимава со управување со инфраструктурата и деноноќна техничка поддршка за веб-проекти: имаме повеќе од 400 клиенти, што е околу 15% од руската е-трговија. Според тоа, поддржана е многу разновидна архитектура. Доколку нешто падне, должни сме да го поправиме во рок од 15 минути. Но, за да разберете дека се случила несреќа, треба да го следите проектот и да реагирате на инциденти. Како да го направите ова?

Сметам дека има проблем да се организира соодветен систем за следење. Да немаше проблеми, тогаш мојот говор ќе се состоеше од една теза: „Ве молиме инсталирајте ги Prometheus + Grafana и приклучоците 1, 2, 3“. За жал, тоа веќе не функционира така. А главниот проблем е што сите продолжуваат да веруваат во нешто што постоело во 2008 година, во однос на софтверските компоненти.

Во однос на организацијата на системот за мониторинг, би се осмелил да кажам дека... проекти со компетентен мониторинг не постојат. И ситуацијата е толку лоша што ако нешто падне, постои ризик да помине незабележано - на крајот на краиштата, сите се сигурни дека „сè се следи“.
Можеби сè се следи. Но како?

Сите сме сретнале приказна како следнава: одреден развој, работи одреден админ, им доаѓа тим за развој и вели - „Ослободени сме, сега следи“. Монитор што? Како работи?

ДОБРО. Ние го следиме старомоден начин. И веќе се менува, и излегува дека сте ја следеле услугата А, која стана услуга Б, која комуницира со услугата C. Но, тимот за развој ви вели: „Инсталирајте го софтверот, тој треба да надгледува сè!

Значи, што се смени? - Се е променето!

2008 година Се е во ред

Има неколку програмери, еден сервер, еден сервер за бази на податоци. Сè оди од тука. Имаме некои информации, инсталираме zabbix, Nagios, кактуси. И тогаш поставуваме јасни предупредувања за процесорот, за работата на дискот и за просторот на дискот. Исто така, правиме неколку рачни проверки за да се осигураме дека страницата реагира и дека нарачките пристигнуваат во базата на податоци. И тоа е тоа - ние сме повеќе или помалку заштитени.

Ако ја споредиме количината на работа што администраторот ја направи тогаш за да обезбеди мониторинг, тогаш 98% од тоа беше автоматски: лицето кое го врши мониторингот мора да разбере како да инсталира Zabbix, како да го конфигурира и да ги конфигурира предупредувањата. И 2% - за надворешни проверки: дека страницата одговара и прави барање до базата на податоци, дека пристигнале нови нарачки.

2010 година Товарот расте

Почнуваме да ја зголемуваме мрежата, додавајќи пребарувач. Сакаме да се увериме дека каталогот на производи ги содржи сите производи. И тоа пребарување на производи функционира. Дека базата на податоци работи, дека се прават нарачки, дека страницата реагира надворешно и одговара од два сервери и дека корисникот не е исфрлен од страницата додека е ребалансиран на друг сервер итн. Има повеќе субјекти.

Покрај тоа, субјектот поврзан со инфраструктурата сè уште останува најголем во главата на менаџерот. Сè уште има идеја во мојата глава дека лицето што го врши мониторингот е лицето кое ќе инсталира zabbix и ќе може да го конфигурира.

Но, во исто време, се појавува работа на спроведување на надворешни проверки, на создавање множество скрипти за барање индекси за пребарување, збир на скрипти за проверка дали пребарувањето се менува за време на процесот на индексирање, збир на скрипти кои проверуваат дали стоките се префрлени во услуга за испорака итн. и така натаму.

Забелешка: Напишав „збир на скрипти“ 3 пати. Односно, одговорното лице за следење повеќе не е тој што едноставно инсталира zabbix. Ова е личност која започнува со кодирање. Но, сè уште ништо не е сменето во главите на тимот.

Но, светот се менува, станува сè покомплексен. Додадени се слој за виртуелизација и неколку нови системи. Тие почнуваат да комуницираат едни со други. Кој рече дека „мириса на микроуслуги? Но, секоја услуга сепак изгледа како веб-страница поединечно. Можеме да се свртиме кон него и да разбереме дека ги дава потребните информации и работи самостојно. И ако сте администратор постојано вклучен во проект кој се развива 5-7-10 години, ова знаење се акумулира: се појавува ново ниво - вие го сфативте, се појавува друго ниво - го сфативте ...

Но, ретко кој придружува проект 10 години.

Биографија на Monitoringman

Да претпоставиме дека дојдовте до нов стартап кој веднаш ангажираше 20 програмери, напиша 15 микросервиси, а вие сте админ кому му е кажано: „Изградете CI/CD. Ве молам“. Изградивте CI/CD и одеднаш слушате: „Тешко ни е да работиме со производство во „коцка“, без да разбереме како апликацијата ќе работи во неа. Направете ни песок во истата „коцка“.
Во оваа коцка правите песок. Веднаш ви велат: „Сакаме сценска база на податоци што се ажурира секој ден од производството, за да разбереме дека работи на базата на податоци, но во исто време да не ја расипе продукциската база на податоци“.

Ти живееш во сето ова. Остануваат уште 2 недели до објавувањето, тие ви велат: „Сега ајде да го следиме сето ова...“ Тоа е. следете ја кластерската инфраструктура, следете ја микросервисната архитектура, следете ја работата со надворешни сервиси...

А моите колеги ја вадат вообичаената шема од глава и велат: „Па, овде сè е јасно! Инсталирајте програма што ќе го следи сето ова. Да, да: Прометеј + Графана + приклучоци.
И тие додаваат: „Имате две недели, бидете сигурни дека сè е безбедно“.

Во многу проекти што ги гледаме, едно лице е распределено за мониторинг. Замислете дека сакаме да вработиме човек да прави мониторинг 2 недели, а ние да му пишуваме резиме. Какви вештини треба да има оваа личност, со оглед на сето она што го кажавме досега?

• Тој мора да го разбере мониторингот и спецификите на работењето на железната инфраструктура.
• Тој мора да ги разбере спецификите на следењето на Kubernetes (и секој сака да оди во „коцката“, затоа што можете да апстрахирате од сè, да се скриете, бидејќи администраторот ќе се занимава со останатото) - самиот себе, неговата инфраструктура и да разбере како да ги следите апликациите внатре.
• Тој мора да разбере дека услугите меѓусебно комуницираат на посебни начини и да ги знае спецификите за тоа како услугите комуницираат едни со други. Сосема е можно да се види проект каде некои сервиси комуницираат синхроно, бидејќи нема друг начин. На пример, задниот дел оди преку REST, преку gRPC до услугата за каталог, добива список на производи и го враќа назад. Не можете да чекате овде. И со други услуги работи асинхроно. Префрлете ја нарачката до услугата за испорака, испратете писмо итн.
  Веројатно веќе сте пливале од сето ова? И админот, кој треба да го следи ова, стана уште повеќе збунет.
• Тој мора да биде способен да планира и планира правилно - како што работата станува се повеќе и повеќе.
• Затоа, тој мора да создаде стратегија од креираната услуга за да разбере како конкретно да ја следи. Нему му треба разбирање на архитектурата на проектот и неговиот развој + разбирање на технологиите што се користат во развојот.

Да се ​​потсетиме на еден апсолутно нормален случај: некои услуги се во PHP, некои услуги се во Go, некои услуги се во JS. Тие некако работат меѓу себе. Оттука доаѓа терминот „микросервис“: има толку многу индивидуални системи што програмерите не можат да го разберат проектот како целина. Еден дел од тимот пишува услуги во JS кои работат сами и не знаат како функционира остатокот од системот. Другиот дел пишува услуги во Python и не се меша со тоа како функционираат другите услуги; тие се изолирани во нивната област. Третиот е пишување услуги во PHP или нешто друго.
Сите овие 20 луѓе се поделени на 15 сервиси, а има само еден админ кој мора да го разбере сето ова. Стоп! ние само го поделивме системот на 15 микросервиси бидејќи 20 луѓе не можат да го разберат целиот систем.

Но треба некако да се следи...

Каков е резултатот? Како резултат на тоа, постои една личност која смислува сè што целиот тим на програмери не може да го разбере, а во исто време тој исто така мора да знае и да може да го направи она што го наведовме погоре - хардверска инфраструктура, инфраструктура Кубернетс итн.

Што да кажам... Хјустон, имаме проблеми.

Следењето модерен софтверски проект е софтверски проект сам по себе

Од лажното верување дека следењето е софтвер, развиваме верување во чуда. Но, чудата, за жал, не се случуваат. Не можете да инсталирате zabbix и да очекувате сè да работи. Нема смисла да се инсталира Графана и да се надеваме дека се ќе биде ок. Поголемиот дел од времето ќе биде потрошено на организирање проверки на работењето на услугите и нивната меѓусебна интеракција, проверка како функционираат надворешните системи. Всушност, 90% од времето ќе биде потрошено не на пишување скрипти, туку на развој на софтвер. И со тоа треба да управува тим кој ја разбира работата на проектот.
Ако во оваа ситуација едно лице биде фрлено на мониторинг, тогаш ќе се случи катастрофа. Што се случува насекаде.

На пример, постојат неколку сервиси кои меѓусебно комуницираат преку Кафка. Стигна нарачката, му испративме порака на Кафка за нарачката. Постои услуга која ги слуша информациите за нарачката и ја испраќа стоката. Постои услуга која слуша информации за нарачката и испраќа писмо до корисникот. И тогаш се појавуваат уште еден куп услуги и почнуваме да се збунуваме.

И ако им го дадете ова на администраторот и на програмерите во фаза кога останува кратко време пред објавувањето, лицето ќе треба да го разбере целиот протокол. Оние. За проект од ваков обем потребно е значително време, и тоа треба да се земе предвид во развојот на системот.
Но, многу често, особено кај стартапите, гледаме како следењето се одложува за подоцна. „Сега ќе направиме Доказ за концепт, ќе лансираме со него, нека падне - подготвени сме да се жртвуваме. И тогаш ќе го следиме сето тоа“. Кога (или ако) проектот почнува да заработува пари, бизнисот сака да додаде уште повеќе функции - затоа што почна да работи, па затоа треба да се прошири понатаму! И вие сте на точка каде што прво треба да следите сè претходно, што не одзема 1% од времето, туку многу повеќе. Патем, програмерите ќе бидат потребни за следење и полесно е да им дозволите да работат на нови функции. Како резултат на тоа, се пишуваат нови функции, сè се заеба, а вие сте во бескраен ќорсокак.

Значи, како да следите проект почнувајќи од почеток, и што да направите ако добиете проект што треба да се следи, но не знаете од каде да започнете?

Прво, треба да планирате.

Лирска дигресија: многу често започнуваат со следење на инфраструктурата. На пример, имаме Kubernetes. Да почнеме со инсталирање на Prometheus со Grafana, инсталирање приклучоци за следење на „коцката“. Не само програмерите, туку и администраторите имаат несреќна практика: „Ќе го инсталираме овој приклучок, но приклучокот веројатно знае како да го направи тоа“. Луѓето сакаат да започнат со едноставни и едноставни, наместо со важни дејства. А следењето на инфраструктурата е лесно.

Прво, одлучете што и како сакате да следите, а потоа изберете алатка, бидејќи другите луѓе не можат да мислат наместо вас. И дали треба? Други луѓе размислуваа за себе, за универзален систем - или воопшто не размислуваа кога беше напишан овој додаток. А само затоа што овој приклучок има 5 илјади корисници не значи дека е од никаква корист. Можеби ќе станете 5001-ви само затоа што претходно таму имало 5000 луѓе.

Ако почнете да ја следите инфраструктурата и задниот дел на вашата апликација престане да реагира, сите корисници ќе ја изгубат врската со мобилната апликација. Ќе се појави грешка. Ќе дојдат кај тебе и ќе ти кажат „Апликацијата не работи, што правиш овде?“ - „Ние следиме“. — „Како следите ако не гледате дека апликацијата не работи?!“

1. Верувам дека треба да започнете со следење токму од влезната точка на корисникот. Ако корисникот не види дека апликацијата работи, тоа е тоа, тоа е неуспех. И системот за следење треба прво да предупреди за ова.
2. И дури тогаш можеме да ја следиме инфраструктурата. Или направете го тоа паралелно. Полесно е со инфраструктурата - овде конечно можеме само да инсталираме zabbix.
3. И сега треба да отидете до корените на апликацијата за да разберете каде работите не функционираат.

Мојата главна идеја е дека следењето треба да оди паралелно со процесот на развој. Ако го одвлечете вниманието на тимот за следење за други задачи (создавање CI/CD, песок, реорганизација на инфраструктурата), следењето ќе почне да заостанува и можеби никогаш нема да го достигнете развојот (или порано или подоцна ќе мора да го запрете).

Сè по нивоа

Вака ја гледам организацијата на мониторинг систем.

1) Ниво на апликација:

• следење на деловната логика на апликацијата;
• следење на здравствената метрика на услугите;
• следење на интеграцијата.

2) Ниво на инфраструктура:

• следење на нивото на оркестрација;
• следење на системскиот софтвер;
• следење на нивото на железо.

3) Повторно ниво на примена - но како инженерски производ:

• собирање и следење на дневници на апликации;
• АПМ;
• трасирање.

4) Предупредување:

• организација на систем за предупредување;
• организација на дежурен систем;
• организација на „база на знаење“ и работен тек за обработка на инциденти.

Важно е: стигнуваме до алармирање не после, туку веднаш! Нема потреба да започнете мониторинг и „некако подоцна“ да дознаете кој ќе добива предупредувања. На крајот на краиштата, која е задачата на мониторингот: да се разбере каде во системот нешто работи погрешно и да се известат вистинските луѓе за тоа. Ако го оставите ова до крај, тогаш вистинските луѓе ќе знаат дека нешто не е во ред само со тоа што ќе повикаат „ништо не работи за нас“.

Слој на апликација - Мониторинг на деловна логика

Овде зборуваме за проверка на самиот факт дека апликацијата работи за корисникот.

Ова ниво треба да се направи во фазата на развој. На пример, имаме условен Прометеј: тој оди до серверот што ги проверува, ја повлекува крајната точка, а крајната точка оди и го проверува API-то.

Кога често се бара да ја следат почетната страница за да се уверат дека страницата работи, програмерите даваат рачка што може да се повлече секој пат кога треба да се уверат дека API работи. И програмерите во овој момент сè уште земаат и пишуваат /api/test/helloworld
Единствениот начин да бидете сигурни дека сè работи? - Не!

• Креирањето такви проверки во суштина е задача на програмерите. Единиците тестови треба да ги напишат програмерите кои го пишуваат кодот. Затоа што ако му го објавите на администраторот, „Друже, еве список со протоколи API за сите 25 функции, ве молиме следете сè! - ништо нема да успее.
• Ако испечатите „здраво свето“, никој никогаш нема да знае дека API треба и функционира. Секоја промена на API мора да доведе до промена во проверките.
• Ако веќе имате таков проблем, запрете ги функциите и распределете програмери кои ќе ги напишат овие проверки или ќе ги прифатат загубите, прифатете дека ништо не е проверено и нема да успее.

Технички совети:

• Бидете сигурни да организирате надворешен сервер за организирање проверки - мора да бидете сигурни дека вашиот проект е достапен за надворешниот свет.
• Организирајте проверки низ целиот API протокол, а не само поединечни крајни точки.
• Направете прометеј-крајна точка со резултатите од тестот.

Слој на апликација - следење на здравствената метрика

Сега зборуваме за надворешни здравствени метрики на услугите.

Решивме да ги следиме сите „рачки“ на апликацијата користејќи надворешни проверки, кои ги нарекуваме од надворешен систем за следење. Но, ова се „рачките“ што корисникот ги „гледа“. Сакаме да бидеме сигурни дека нашите услуги самите работат. Овде има подобра приказна: K8s има здравствени проверки, така што барем самата „коцка“ може да се увери дека услугата работи. Но, половина од чековите што ги видов се со ист печатен „здраво свето“. Оние. Така, тој влече еднаш по распоредувањето, тој одговори дека сè е во ред - тоа е сè. И услугата, ако обезбедува сопствено API, има огромен број влезни точки за истиот API, кој исто така треба да се следи, бидејќи сакаме да знаеме дека функционира. А ние веќе го надгледуваме внатре.

Како правилно да се имплементира ова технички: секоја услуга изложува крајна точка за нејзините моментални перформанси, а во графиконите на Grafana (или која било друга апликација) го гледаме статусот на сите услуги.

• Секоја промена на API мора да доведе до промена во проверките.
• Создадете нова услуга веднаш со здравствени метрики.
• Администраторот може да дојде кај програмерите и да праша „додајте ми неколку функции за да разберам сè и да додадам информации за ова во мојот систем за следење“. Но, програмерите обично одговараат: „Нема да додадеме ништо две недели пред објавувањето“.
  Нека знаат менаџерите за развој дека ќе има такви загуби, нека знаат и менаџментот на менаџерите за развој. Затоа што кога сè ќе падне, некој сепак ќе се јави и ќе бара да ја следи „сервисот што постојано паѓа“ (в)
• Патем, распределете ги програмерите да пишуваат приклучоци за Grafana - ова ќе биде добра помош за администраторите.

Слој на апликација - Мониторинг на интеграција

Мониторингот за интеграција се фокусира на следење на комуникациите помеѓу деловните критични системи.

На пример, има 15 сервиси кои меѓусебно комуницираат. Овие повеќе не се посебни локации. Оние. не можеме сами да ја повлечеме услугата, да добиеме /helloworld и да разбереме дека услугата работи. Бидејќи веб-услугата за нарачка мора да испрати информации за нарачката до автобусот - од автобусот, сервисот за складиште мора да ја добие оваа порака и понатаму да работи со неа. И услугата за дистрибуција на е-пошта мора да го обработи ова некако понатаму, итн.

Според тоа, не можеме да разбереме, лупајќи по секоја поединечна услуга, дека сето тоа функционира. Затоа што имаме одреден автобус преку кој сè комуницира и комуницира.
Затоа, оваа фаза треба да ја означи фазата на тестирање на услугите за интеракција со други услуги. Невозможно е да се организира следење на комуникацијата со следење на брокерот за пораки. Ако постои услуга што издава податоци и услуга што ги прима, при следење на брокерот ќе видиме само податоци што летаат од страна на страна. Дури и ако некако успеавме да ја следиме интеракцијата на овие податоци внатре - дека одреден производител ги објавува податоците, некој ги чита, овој тек продолжува да оди до Кафка - ова сепак нема да ни даде информации ако една услуга ја испрати пораката во една верзија. , но другиот сервис не ја очекуваше оваа верзија и ја прескокна. Нема да знаеме за ова, бидејќи службите ќе ни кажат дека сè работи.

Што препорачувам да се направи:

• За синхрона комуникација: крајната точка испраќа барања до поврзаните услуги. Оние. ја земаме оваа крајна точка, повлекуваме скрипта внатре во услугата, која оди до сите точки и вели „Можам да повлечам таму, и да повлечам таму, можам да повлечам таму...“
• За асинхрона комуникација: дојдовни пораки - крајната точка ја проверува магистралата за тест пораки и го прикажува статусот на обработка.
• За асинхрона комуникација: појдовни пораки - крајната точка испраќа тест пораки до автобусот.

Како што обично се случува: имаме услуга која фрла податоци во магистралата. Доаѓаме до оваа услуга и ве замолуваме да ни кажете за здравјето на нејзината интеграција. И ако услугата треба да произведе порака некаде понатаму (WebApp), тогаш ќе ја произведе оваа тест порака. И ако извршиме услуга на страната на Обработка на нарачки, таа прво објавува што може да објави независно, а ако има некои зависни работи, тогаш чита збир на тест пораки од автобусот, разбира дека може да ги обработи, пријави и , ако треба постирајте ги понатаму, а за ова вели - се е ок, жив сум.

Многу често го слушаме прашањето „како можеме да го тестираме ова на борбени податоци? На пример, зборуваме за истата услуга за нарачка. Нарачката испраќа пораки до магацинот каде што се отпишуваат стоките: не можеме да го тестираме ова на борбени податоци, бидејќи „мојата стока ќе биде отпишана!“ Решение: Планирајте го целиот овој тест на самиот почеток. Имате и единечни тестови кои прават потсмев. Така, направете го тоа на подлабоко ниво каде што имате канал за комуникација што не му штети на работењето на бизнисот.

Ниво на инфраструктура

Мониторингот на инфраструктурата е нешто што долго време се сметаше за самото мониторирање.

• Мониторингот на инфраструктурата може и треба да се започне како посебен процес.
• Не треба да започнувате со следење на инфраструктурата на тековниот проект, дури и ако навистина сакате. Ова е болка за сите луѓе. „Прво ќе го надгледувам кластерот, ќе ја следам инфраструктурата“ - т.е. Прво, ќе следи што лежи подолу, но нема да влезе во апликацијата. Затоа што апликацијата е неразбирлива работа за devops. Нему му беше протечено, а тој не разбира како функционира. И тој ја разбира инфраструктурата и почнува со неа. Но, не - секогаш треба прво да ја следите апликацијата.
• Не претерувајте со бројот на предупредувања. Со оглед на сложеноста на современите системи, предупредувањата постојано летаат, а вие некако треба да живеете со овој куп предупредувања. И лицето на повик, откако погледна сто од следните предупредувања, ќе одлучи „Не сакам да размислувам за тоа“. Известувањата треба да известуваат само за критични работи.

Ниво на апликација како деловна единица

Клучните точки:

• ЕЛК. Ова е индустриски стандард. Ако поради некоја причина не собирате дневници, почнете да го правите тоа веднаш.
• АПМ. Надворешни APM како начин за брзо затворање на следењето на апликациите (NewRelic, BlackFire, Datadog). Можете да го инсталирате ова нешто привремено за барем некако да разберете што се случува со вас.
• Следење. Во десетици микроуслуги, мора да следите сè, бидејќи барањето повеќе не живее самостојно. Многу е тешко да се додаде подоцна, па затоа е подобро веднаш да се закаже следењето во развојот - ова е работа и корисност на програмерите. Ако сè уште не сте го имплементирале, имплементирајте го! Видете Јегер/Зипкин

Алармантно

• Организација на систем за известување: во услови на следење на куп работи треба да има унифициран систем за испраќање известувања. Можеш во Графана. На Запад, сите користат PagerDuty. Предупредувањата треба да бидат јасни (на пр. од каде доаѓаат...). И препорачливо е да се контролира дали воопшто се примаат известувања
• Организација на дежурен систем: предупредувањата не треба да се испраќаат до сите (или сите ќе реагираат во толпа, или никој нема да реагира). Програмерите, исто така, треба да бидат на повик: задолжително дефинирајте ги областите на одговорност, дајте јасни упатства и напишете во него кој точно да се јави во понеделник и среда и кој да се јави во вторник и петок (инаку нема да повикаат никого дури и во настан на голем проблем - ќе се плашат да ве разбудат или да ви пречат: луѓето генерално не сакаат да се јавуваат и да будат други луѓе, особено ноќе). И објаснете дека барањето помош не е показател за неспособност („Барам помош, тоа значи дека сум лош работник“), поттикнете ги барањата за помош.
• Организација на „база на знаење“ и работен тек за обработка на инцидентот: за секој сериозен инцидент треба да се планира постмортам, а како привремена мерка треба да се евидентираат дејствија што ќе го разрешат инцидентот. И направете пракса дека повторените предупредувања се грев; тие треба да се поправат во код или инфраструктурна работа.

Технолошки оџак

Да замислиме дека нашиот оџак е како што следува:

• прибирање податоци - Прометеј + Графана;
• анализа на дневници - ЕЛК;
• за APM или Tracing - Jaeger (Zipkin).

Изборот на опции не е критичен. Затоа што ако на почетокот разбравте како да го надгледувате системот и запишавте план, тогаш почнувате да избирате алатки што одговараат на вашите барања. Прашањето е што одбравте да следите на прво место. Затоа што можеби алатката што ја избравте на почетокот воопшто не одговара на вашите барања.

Неколку технички точки што ги гледам насекаде во последно време:

Прометеј го туркаат во Кубернетес - кој го смисли ова?! Ако вашиот кластер се сруши, што ќе направите? Ако имате комплексен кластер внатре, тогаш треба да има некој вид на систем за следење внатре во кластерот, а некој надвор, кој ќе собира податоци од внатрешноста на кластерот.

Внатре во кластерот собираме трупци и се останато. Но, системот за следење мора да биде надвор. Многу често, во кластер каде што има внатрешно инсталиран Promtheus, постојат и системи кои вршат надворешни проверки на работата на страницата. Што ако вашите врски со надворешниот свет паднале и апликацијата не работи? Излегува дека сè е добро внатре, но тоа не им ги олеснува работите на корисниците.

Наоди

• Следењето на развојот не е инсталирање на комунални услуги, туку развој на софтверски производ. 98% од денешниот мониторинг е кодирање. Кодирање во услуги, кодирање надворешни проверки, проверка на надворешни услуги и тоа е сè.
• Не трошете го времето на вашите програмери на мониторинг: може да потрае до 30% од нивната работа, но вреди.
• Девопс, не грижете се дека не можете да следите нешто, бидејќи некои работи се сосема поинаков начин на размислување. Не си бил програмер, а следењето на работата е токму нивна работа.
• Ако проектот веќе работи и не се следи (а вие сте менаџер), доделете ресурси за следење.
• Ако производот е веќе во производство, а вие сте девоп кому му било кажано да „поставите мониторинг“ - обидете се да му објасните на раководството за што го напишав сето ова.

Ова е проширена верзија на извештајот на конференцијата Saint Highload++.

Ако ве интересираат моите идеи и размислувања за тоа и сродните теми, тогаш тука можете прочитајте го каналот 🙂

Извор: www.habr.com