CASE metodu: humanist monitorinq

CASE metodu: humanist monitorinq
Dziiiiin! Səhər saat 3-dür, gözəl yuxu görürsən və birdən zəng gəlir. Bu həftə növbətçisiniz və görünür nəsə olub. Avtomatlaşdırılmış sistem nəyin səhv olduğunu öyrənmək üçün zəng edir. Bu, müasir kompüter sistemlərinin idarə olunmasının vacib aspektidir, lakin gəlin bildirişləri insanlar üçün daha yaxşı etmək üçün necə baxaq.

Müxtəlif monitorinq qruplarında bir neçə onilliklər ərzində vəzifəmi yerinə yetirdiyim monitorinq fəlsəfəsi ilə tanış olun. O, əsasən Rob Evaşçukun həqiqi İncilindən təsirləndi Xəbərdarlıq haqqında fəlsəfəm (My Notification Philosophy) mövzusunda kitaba daxil edilmişdir Google SRE, və John Alspaugh tərəfindən kitab Xəbərdarlığın Dizaynı üçün Mülahizələr (Xəbərdarlıqların qurulması ilə bağlı qeydlər).

Kelly Dann, Arijit Mukhery и Maksim Petazzoni - yazının redaktə edilməsində köməyinizə görə təşəkkür edirik.

CASE nədir?

kimi gözəl bir abbreviatura ilə gəlməyə qərar verdim Brendan Qreqin İSTİFADƏ metodu və ya Tom Wilkie-nin RED metodu. Mən onu çağırıram CASE metodu. O, avtomatik monitorinqlə işləyərkən diqqət edilməli olan dörd məqamı təsvir edir:

Əgər siz CASE-dən istifadə edirsinizsə, bildirişlərə sağlam laqeyd yanaşırsınız və gecələr insanları yuxudan oyatmazsınız. Monitorinq mütəmadi olaraq faydalılıq və effektivlik baxımından qiymətləndirilməlidir. Bir şəxs bildiriş aldıqda, daha yaxşı zehni modellərə və daha çox güvənə sahib olacaq.

Yadda saxlamağı asanlaşdırmaq üçün təsəvvür edin ki, sizə CASE [yəni bir iş, səbəb - tərcüməçinin qeydi] hər bir xəbərdarlığı əsaslandırmaq üçün. :günəş eynəyi:

Və bütün bunlar niyə?

Növbətçi olmaq ağrılı ola bilər. Bir çox səbəblərə görə. Və CASE onların hamısını aradan qaldırmayacaq. Bununla birlikdə, gecə daha yaxşı bildirişlər üçün oyanacaqsınız. Bu üsul bu məsələdə də kömək edəcək müxtəlif təşkilati prosesləri əhatə edir.

RED və USE metodlarının gözəlliyi ondadır ki, onların köməyi ilə biz nəinki işləməyi bilirik, həm də bir-birimizlə eyni dildə danışırıq. Ümid edirəm ki, CASE metodu sistemimizi qoruyan, lakin həmkarlarımızı məşğul saxlayan bildirişləri müzakirə etməyi asanlaşdıracaq.

Məsələ burasındadır ki, siz təşkilatınızda bildirişlərə sağlam laqeyd yanaşılacaq bir mədəniyyət yaratmalısınız. Bildirişlər müəyyən bir məqsəd üçün yaradıla bilər, lakin sonradan dəyərini itirməyəcəkləri fakt deyil. Bu bildirişi niyə quraşdırdıq? Onun meyarlarına nə vaxtdan yenidən baxılıb? CASE ilə bu suallara cavab tapmaq olar.

Context-Heavy - kontekst bağlama

Səhər saat 3-də çoxlu ağıllı sözlərdən ibarət mesajları oxumaq üçün ən yaxşı vaxt deyil. Effektiv cavab vermək üçün sizə məlumat lazımdır. İdeal olaraq, bu, kontekst dərhal aydın olan konkret məsələ haqqında məlumat olmalıdır və bildirişlər bunun mümkün olması üçün konfiqurasiya edilməlidir. Bu, "müşahidə" və "oriyentasiya"dır OODA döngəsi. Bu quraşdırmaya vaxt sərf etmək ayıb deyil, çünki bir insanın daim diqqətini yayındırmaq daha bahalıdır. Bir-birimizə hörmət edək.

CASE metodu: humanist monitorinq
Problemlərin çoxlu mənbələri var. Xüsusilə də xəyallar.

Növbətçiyə necə kömək edə bilərəm? Növbətçinin gördüyü ilk şey bildirişdir, ona görə də bütün fərziyyələri onun əsasında qurur. Sonra təlimatlara və tablolara baxır, ancaq ümumi məlumat deyil, hər zaman xüsusi bir bildirişdə məlumatlar varmı? Alspaugh "bildirişi necə şərh edə və ya cavab verə biləcəyinizi düşünməyi" tövsiyə edir (slayd 29)1. Yaxşı bir bildiriş yalnız bir həddi ilə konfiqurasiya olunmur, növbətçi şəxsə yönəldilmişdir.

Beləliklə, burada bildiriş kontekstini yaxşılaşdırmaq üçün bəzi fikirlər var:

  • İstifadəçiyə yalnız adi təlimatlar və ya tablosunu deyil, faydalı və xüsusi yaradılmış bir şey göstərin. Əvvəllər uşaqlar və mən xüsusi bildirişlər üçün konfiqurasiya edilmiş istintaq idarə panellərindən istifadə etdik. Bu, problemin bilindiyi təqdirdə kömək edəcək, ancaq başqalarını çaşdıracaq. Burada tarazlıq tapmalıyıq.
  • Bildirişin tarixi haqqında bizə məlumat verin: bu yenidir? Tez-tez işləyir? Mövsümidir?
  • Sistem vəziyyətində son dəyişiklikləri göstərin. Bu yaxınlarda bir şey dəyişdi? (Məsələn, yerləşdirmə və ya funksionallığın aktivləşdirilməsi/deaktiv edilməsi.)
  • Əlaqələri göstərin və zehni model üçün məlumat verin: sistem asılılıqları, tercihen funksionallıq göstəricisi ilə aydın görünməlidir.
  • İstifadəçini komanda ilə sürətlə əlaqələndirin: onlar davam edən hadisələri görə bilirlər və ya şirkətdə daha kimin bildiriş aldığını öyrənə bilərlərmi? Proqram hadisələrin idarə edilməsi aktivləşdirilib?

İdeal olaraq, insidentlərin idarə edilməsi proqramı insident araşdırmalarının bildiriş kontekstinin yaxşılaşdırılmasına dair məsləhət verəcəkdir. Həmişə üzərində işləmək üçün bir şey var!

Fəaliyyətli - praktiki dəyər

Xəbərdarlığa cavab olaraq növbətçi nəsə etməlidir? Əgər heç bir şey etmək lazım deyilsə və ya nə edəcəyiniz aydın deyilsə, onu niyə oyatdınız? Növbətçiləri narahat edən və hərəkət tələb etməyən bildirişlərdən qaçınmalısınız.

Imgur.com bax post

Mən nə etməliyəm? Nə istəyirsən?

Keçmişdə, sistemlər sadə və komandalar kiçik olanda, biz yalnız hər şeydən xəbərdar olmaq üçün monitorinq qurmuşduq. Yığındakı yükün artdığına dair bildiriş, xidmət sonradan nasazlaşarsa, bizə kontekst verəcəkdir. Geniş miqyasda bu cür bildirişlər yalnız çaşqınlıq yaradacaq, çünki sistemlərimiz həmişə müxtəlif şiddətdə deqradasiya vəziyyətində işləyir. Bu tez gətirib çıxarır bildirişlərdən yorğunluq və təbii ki, həssaslığın itirilməsi. Buna görə də, növbətçi belə bildirişlərə məhəl qoymur, hətta onları süzgəcdən keçirir və lazım gəldikdə onlara heç də həmişə cavab vermir. Bu tələyə düşməyin! Bütün bildirişləri ard-arda quraşdırmayın və sonra onları e-poçtla bəzi allahın unutmuş qovluğuna göndərin.

Praktik dəyərə malik bildiriş belə görünür:

  • Bildiriş sadəcə xəbər verməkdən daha çox hərəkət tələb edir.
  • Bu hərəkəti avtomatlaşdırmaq çətindir və ya risklidir. Bir hərəkəti avtomatlaşdırmaq olarsa, onu avtomatlaşdırın, insanları incitməyi dayandırın!
  • Bildiriş formada təcili tövsiyələri ehtiva edir xidmət səviyyəsi müqavilələri (SLA) və ya bərpa vaxtı hədəfi (RTO). Bundan sonra növbətçi təşkilatın insidentlərin idarə edilməsi proqramını aktivləşdirə bilər.

Mən aydınlaşdırmaq istəyirəm: bildirişlərin yalnız API üçün ən vacib SLO (xidmət səviyyəli məqsədlər) üçün gəlməsini demirəm. SLO monitorinqi daima parçalanır və bölünür və bütün xidmətlərə eyni yanaşma tələb edir. Aydındır ki, sizə ödəniş edən müştərilər üçün ən vacib SLO-ları izləyəcəksiniz. Lakin verilənlər bazası kimi infrastruktur SLO-larına da nəzarət edilməlidir. Tezliklə daxili müştərilərlə məşğul olmalı və onlara dəstək olmalı olacaqsınız. Və s sonsuza qədər.

Simptomlara əsaslanan - simptomlara vurğu

İstəsəniz də, istəməsəniz də paylanmış sistemdə işləyirsiniz (Kavaj)2. Nəticədə siz xidmətləri təcrid etmək və onları uğursuzluqdan qorumaq üçün müxtəlif taktikalardan istifadə edirsiniz (Trainor et al.)3. Gecikmiş zibil yığımı və ya dayanmış verilənlər bazası sorğusu problemləri göstərsə də, istifadəçilərin yaxın gələcəkdə problemi olmadıqda onları düzəltməyə tələsməyə ehtiyac yoxdur.

Bunlar vacib siqnallardır və praktiki əhəmiyyətə malik ola bilər, lakin istifadəçiləri narahat etmirsə, o zaman xidmətçinin diqqətini yayındırmaq üçün kifayət qədər təcili deyil. Səbəb əsaslı bildirişlər sistem nasazlığı haqqında zehni modellərimizin anlıq görüntüləridir. Uğursuzluğun bütün mümkün səbəblərini sadalamağa çalışmaqdansa, vacib simptomları izləmək daha yaxşıdır.

Bildirişləri mənalı etmək üçün diqqət edin performans göstəriciləri, istifadəçilər üçün vacibdir. Evaşçuk bunu “istifadəçilər üçün monitorinq” adlandırır. Unutmayın ki, bu fəlsəfə bütün təşkilatda tətbiq edilməlidir. Xidmətin infrastrukturun dərinliklərində təcili problemlər varsa, müvafiq komanda onlarla maraqlanacaq. Sistemləri bu cür uğursuzluqlardan qorumaq tamamilə ayrı bir məsələdir (Trainer et al., kritik asılılıqları minimuma endirmək üçün strategiyalar bölməsi)3.

Semptomlar o qədər də dəyişkən deyil

Riçard Kuk bizə xatırladır ki, mürəkkəb sistemlər qüsurlar, çatışmazlıqlar və problemlərlə doludur4. Bütün mümkün səbəbləri sadalamağa çalışmaq Sizif vəzifəsidir. Problemləri təsvir etməyə çalışırsınız, lakin onlar hər zaman dəyişir. Cindy Sridharan hesab edir ki, "sistemlər hər saniyə mükəmməl vəziyyətdə olmaq məcburiyyətində deyil" və daha insani yanaşmadan istifadə etmək daha yaxşıdır ("Paylanmış Sistemlərin Müşahidə Edilməsi" (“Paylanmış Sistemlərin Monitorinqi”), 7)5.

Hadisədən sonra bildirişlərdən çəkinin

Bir qayda olaraq, səbəblərə dair bildirişlər hadisələri düzəltmək üçün konfiqurasiya edilir. Və baş verənlərin faktı ilə bağlı bu məhdud bildirişlər yanlış təhlükəsizlik hissi yaradır, çünki sistem hər dəfə sındırmaq üçün yeni yollar təklif edir.

Səbəb bildirişlərinə aldanmayın. Daha yaxşı düşün:

  • Niyə simptoma əsaslanan bildiriş problemi qeyd etmədi?
  • İstifadəçi üçün konteksti təkmilləşdirmək faydalı ola bilərmi?
  • Baş verənlərlə bağlı bildirişləri toplamaq əvəzinə, diaqnozu daha sürətli etmək üçün monitorinq alətlərini necə təkmilləşdirmək olar?

Diaqnoz üçün monitorinq alətləri yalnız simptomdan həll yoluna keçməyin bir yolu kimi düşünsəniz kömək edəcəkdir. Bu geribildirim olmadan, sadəcə olaraq, keçmiş uğursuzluqlar haqqında gec bildirişlər və qrafiklərlə bombardman ediləcəksiniz və gələcək uğursuzluqlar haqqında bir söz deyil. Bu, bir təşkilatın müdafiədən hücuma keçməsi üçün əla fürsətdir. Tərtibatçıların və məhsul menecerlərinin eyni gözləntiləri və aydın məqsədləri olacaq. İş - CASE (:wink:) - hər bildiriş üçün aydındır.

Səbəblərə əsaslanan bildirişlər nəzarətdə saxlanıla bilər

Bəzən sistemimiz səbəbə əsaslanan bildirişlər baxımından bizə az seçim buraxır. Və bəzən növbətçilər əla başa düşürlər ki, bir əlamət mütləq uğursuzluğa səbəb olacaq və buna görə də praktiki əhəmiyyət kəsb edir. Bəlkə də nə baş verdiyindən əmin deyilsiniz və təhlükəsiz tərəfdə olmaq üçün bildirişlər qurursunuz. Ümid edirik ki, performans problemini həll etmək üçün sistemi dəyişənə qədər bu hərəkət müvəqqətidir.
Bu vəziyyətlərlə məşğul olarkən CASE-in digər komponentlərini yadda saxlayın. Bunun müvəqqəti olması sizin başınızla düşünməyi dayandıra biləcəyiniz demək deyil.

Qiymətləndirilmiş - qiymətləndirmə

Sistemdə edilən hər hansı dəyişiklik (yeni kod, yeni infrastruktur, yeni hər şey) uğursuzluqların diapazonunu genişləndirir (Kuk, 3).4 Bu bildiriş hələ də gözlənildiyi kimi işləyir? Sistemlərin aydın və cari psixi modelləri və bəzi dəstək bildirişlərinə cavab verən təcrübə profilaktik yanaşma - bunlar əsas xüsusiyyətlərdir öyrənmə yönümlü təşkilat. Sistemlərdəki qüsurlar daim inkişaf edir və biz onlarla ayaqlaşmalıyıq.

Hər bildirişin gözlənildiyi kimi işləməsini təmin etmək üçün onun keyfiyyətini daim qiymətləndirməlisiniz. Hörmətli rəhbərlər! Bu prosesi qurmağa kömək etsəniz, komandalarınız üçün çox asan olacaq! Budur bəzi qiymətləndirmə fikirləri:

  • İstifadə edin xaos mühəndisliyi, oyun günləri və ya digər bildiriş test üsulları. Komanda ağır hadisələrin idarə edilməsi sisteminə etibar etmədən bunu özləri edə bilər!
  • Hadisə ilə bağlı bütün bildirişlərin toplusunu hadisənin idarə edilməsi proqramınıza daxil edin. Faydalı, zərərli, uyğunsuz, anlaşılmaz və s. işarələyin. Onları rəy kimi istifadə edin.
  • Düzgün bildirişlər nadir hallarda işə salınır və diqqətlə yoxlanılır. Bütün bağlantıların işlədiyinə əmin olun, düzgün konteksti göstərin və s.
  • Bildiriş heç vaxt tez-tez açılmırsa və ya tez-tez alışırsa, onda nəsə səhv var. Onu düzəldin və ya çıxarın. Həddindən artıq passivlik və ya fəaliyyətdən çəkinin!
  • Bitmə tarixləri ilə bildiriş vaxt möhürlərini təyin edin. İstifadə müddəti bitibsə, CASE metodundan istifadə edərək bildirişi qiymətləndirin və vaxt damğasını yeniləyin. Yemək kimi, son istifadə tarixini mütəmadi olaraq yoxlayın.
  • Bildirişlərin təkmilləşdirilməsi prosesini sadələşdirin. Monitorinqi kod kimi istifadə edin və bildirişləri Git deposunda saxlayın. Çəkmə sorğuları komandanı cəlb etməyə kömək edir və sizə keçmiş bildirişlərin tarixini verir. Və siz artıq bildirişləri dəyişdirməkdən və ya onlara cavabdeh olanlardan icazə istəməkdən qorxmayacaqsınız.
  • Sadə olsa belə, bildirişlər üçün rəy qurun Google forması, beləliklə, növbətçilər bildirişləri yararsız və ya müdaxilə kimi qeyd edirlər. Bildirişin özünə keçid və ya hərəkətə çağırış yerləşdirin və mütəmadi olaraq rəyinizi nəzərdən keçirin.
  • Komandada qayda yaradın - iş az olanda növbətçilər vəzifəni sadələşdirməyə çalışsınlar. Səndən sonra hər şey əvvəlkindən bir az daha yaxşı olsun.

Nəticə

İnanıram ki, CASE metodu tərtibatçılara və təşkilatlara avtomatlaşdırılmış bildirişlərin qurulması və göndərilməsini müzakirə etməyə kömək edir. Bir tərtibatçı CASE metodundan istifadə edərək bildirişləri qiymətləndirməyə başlaya bilər və sonra bütün təşkilat bildirişləri yaxşı vəziyyətdə saxlamaq üçün digər tərtibatçılar, idarəetmə və insidentlərin idarə edilməsi proqramlarına qoşulacaq. Bunun üçün heç bir xüsusi alət və ya mürəkkəb proseslər tələb olunmur.

Bütün sənaye yüksək səviyyəli müştəri xidmətlərindən imtina etmədən vəzifə yerinə yetirərkən insan amili haqqında düşünməlidir. Bütün bu alətlər və təcrübələr təkmilləşdirilə bilər və təkmilləşdirilməlidir. Ümid edirəm ki, CASE metodu bu işdə kömək edəcək.

Təkmil bildirişlərdən həzz alın!
CASE metodu: humanist monitorinq

Mənbə: www.habr.com

Добавить комментарий