Модерните дистрибуирани системи не успеваат на начини што никој од корисниците не може целосно да ги предвиди. Микро-услугата која беше совршено здрава во 2:00 часот наутро може да се каскадира во целосно прекинување до 2:03 часот наутро, оставајќи ги инженерите на повик да се борат низ табла и протоколи на дневници додека крајните корисници доживуваат деградирана услуга. Стариот модел на реактивен одговор на инциденти, каде што луѓето ги детектираат, дијагностицираат и поправаат проблемите, едноставно не можат да го следат темпото со скалата и комплексноста на денешната инфраструктура. Observability as the Foundation Набљудувањето како основа Само-лекувањето започнува со длабоко набљудување. За разлика од традиционалното набљудување, кое се потпира на предодредени прагови и статички табла, вистинската набљудуваност значи дека можете да поставувате произволни прашања за внатрешната состојба на вашиот систем користејќи ги податоците што ги емитира. Ова бара три столбови кои работат во согласност: метрики, дневници и дистрибуирани траги. Метриките ви даваат сигнали од временската серија како што се искористувањето на процесорот, процентилите на задоцнување на барањето и стапките на грешка. Практичната имплементација вклучува инструментирање на секоја услуга со OpenTelemetry, новиот стандард за собирање на телеметрија од страна на продавачите. Кога секоја услуга емитува конзистентни, семантички богати сигнали, вашата платформа за набљудување станува единствен извор на вистина за она што всушност се случува во производството. Алатки како Prometheus, Grafana, Jaeger и OpenSearch го сочинуваат 'рбетот на овој гасовод, ингестирајќи милијарди податоци дневно и правејќи ги истражувачки во речиси реално време. Добивањето на оваа основа е не-преговарачко. Без висококвалитетни, ниско-латентни телеметриски податоци, секој слој на интелигенција изграден на него ќе произведе неверојатни резултати. Where AIOps Enters the Picture Каде AIOps влегува во сликата AIOps платформите седат на врвот на вашиот слој на набљудување и го применуваат машинското учење за да го направат она што луѓето не можат да го направат на скала: корелација на илјадници сигнали истовремено, идентификување на обрасци кои претходат на неуспеси и разликување на вистинските аномалии од бучавата на нормалната системска варијанта. Детекцијата на аномалии во овој контекст не е само предупредување кога метриката поминува статички праг. Добрите AIOps системи користат ненадгледувано учење за да изградат динамички базични линии кои се прилагодуваат на вашите модели на сообраќај, сезонскоста и фреквенцијата на распоредувањето. Пик во латентноста на барањето на базата на податоци во 11:55 часот на понеделник може да биде совршено нормално за вашето работно оптоварување, додека истиот пик во 3:00 часот во недела вреди да се разбуди некој. Корелацијата на настаните е подеднакво важна. Еден инфраструктурен инцидент често предизвикува стотици предупредувања истовремено низ различни системи за следење. Без корелација, вашиот инженер на повик добива страница од 200 пати во три минути, од кои повеќето се симптоми наместо причини. AIOps платформи како Moogsoft, BigPanda и AIOps слој на PagerDuty користат алгоритми базирани на графикони и временска анализа за да ги срушат бурите на предупредувања во еден акционен инцидент, означувајќи ја веројатноста за коренска причина за респондентот. Automated Incident Remediation in Practice Автоматизирано отстранување на инциденти во пракса Откривањето на проблемот побрзо е вредно. Поправувањето на проблемот без човечка интервенција е трансформативно.Автоматизираното отстранување вклучува изградба на библиотека од активности во книгата за извршување кои можат да се активираат програмски кога се исполнети специфични услови, и ова е местото каде архитектурата станува навистина интересна. Практична почетна точка е да се идентификуваат првите десет инциденти по фреквенција во текот на изминатите шест месеци. За многу тимови, оваа листа вклучува работи како што се подови кои исчезнуваат од меморијата, пополнување на дисковите, резервирање на редови поради бавни потрошувачи или истекување на сертификат. Овие се добро разбрани начини на неуспех со повторувачки чекори за поправка: рестартирање на под, чистење на стари дневници, проширување на група на потрошувачи, ротирање на сертификат. Архитектурата изгледа приближно вака: вашата платформа AIOps детектира аномалија и ја корелира со познат модел на неуспех. Потоа предизвикува веб-шок или порака за автобус на настани до вашиот оркестар за автоматизација, кој ја извршува соодветната акција на перникот против вашите инфраструктурни АПИ. Резултатот, без разлика дали е успешен или неуспешен, е напишан назад на вашата платформа за набљудување како структуриран настан, затворање на линкот за повратни информации. Ако автоматската акција не успее или ако довербата во дијагнозата е под дефиниран праг, системот се ескалира до човечки одговор со сите релевантни контексти претходно населени во билетот за инциденти. Автоматизираните системи кои дејствуваат на производната инфраструктура без соодветни заштитни мерки може значително да ги влошат инцидентите. Секоја акција за автоматизација треба да има дефиниран радиус на експлозија, режим на суво возење, механизам за враќање назад и прекинувач на кола кој ги запира автоматските дејства ако се активираат премногу поправки во краток прозорец. Довербата во системот се гради постепено: започнувајте со дејствија со низок ризик во не-производствени средини, строго мерете ги резултатите и проширете го опфатот на автоматизацијата само како што се зголемува довербата. Measuring What Matters Мерење на она што е важно Деловниот случај за инфраструктура за само-лекување се мери преку неколку клучни метрики за доверба. Просечното време за откривање (MTTD) зафаќа колку брзо површината на аномалиите. Просечното време за поправање (MTTR) мери колку долго е потребно за да се врати услугата. Покриеноста на автоматизацијата, процентот на инциденти целосно решени без човечка интервенција, ви кажува колку е зрела вашата библиотека за поправање. И трендовите во обемот на инцидентите покажуваат дали вашите инвестиции за само-лекување всушност ја намалуваат фреквенцијата на неуспеси или едноставно се справуваат со неуспеси повеќе грациозно. Организациите кои сериозно инвестираа во овој простор обично известуваат за намалување на МТД од 50 проценти или повеќе, намалување на МТТР од 40 до 70 проценти и стапки на покривање на автоматизација од 30 до 60 проценти од вкупниот обем на инциденти во рок од 18 месеци од почетната инвестиција. The Road Ahead Патот напред Инфраструктурата за само-лекување не е дестинација што ја достигнувате, а потоа престанувате. Тоа е пракса која се развива како вашите системи растат и вашите начини на неуспех се менуваат. Тимовите што го прават ова најдобро ги третираат своите водичи за автоматизација како производствен код: верзионирани, тестирани, ревидирани и континуирано рафинирани врз основа на вистинските исходи од инциденти. Тие ги интегрираат своите податоци за набљудување со нивните системи за управување со промени, така што моделите на AIOps можат да ги земат предвид неодамнешните распореди при дијагностицирање на аномалии. Конечната цел е инфраструктура која не е само набљудувана и автоматизирана, туку навистина отпорна: една која го предвидува неуспехот, реагира интелигентно и постојано ја подобрува сопствената позиција на доверба.
