دزیییین! ساعت 3 بامداد است، شما یک رویای فوق العاده می بینید، و ناگهان یک تماس به گوش می رسد. شما این هفته در حال انجام وظیفه هستید و ظاهراً اتفاقی افتاده است. سیستم خودکار تماس می گیرد تا بفهمد چه مشکلی دارد. این یکی از جنبه‌های مهم مدیریت سیستم‌های رایانه‌ای مدرن است، اما بیایید به نحوه بهتر کردن اعلان‌ها برای افراد نگاه کنیم.
با فلسفه نظارت که طی چندین دهه از وظایف من در تیم های نظارتی مختلف متولد شده است آشنا شوید. او تا حد زیادی تحت تأثیر کتاب مقدس واقعی راب اواشچوک قرار گرفت (فلسفه اطلاع رسانی من) موجود در کتاب در و کتابی از جان آلسپاگ (یادداشت در مورد تنظیم هشدار).
, и - با تشکر از کمک شما در ویرایش پست.
CASE چیست؟
تصمیم گرفتم یک مخفف زیبا مانند یا . من آن را صدا می زنم روش CASE. وی چهار نکته را در هنگام کار با مانیتورینگ خودکار بیان می کند:
- (محدود به بافت)
- (ارزش عملی)
- (تاکید بر علائم)
- (مقطع تحصیلی)
اگر از CASE استفاده می‌کنید، با اعلان‌ها بی‌تفاوت رفتار می‌کنید و مردم را در شب بیدار نمی‌کنید. نظارت باید به طور منظم برای سودمندی و اثربخشی ارزیابی شود. زمانی که فردی اعلان را دریافت می کند، مدل های ذهنی بهتر و اعتماد به نفس بیشتری خواهد داشت.
برای اینکه راحت‌تر به خاطر بسپارید، تصور کنید که به یک مورد نیاز دارید [یعنی یک مورد، یک دلیل - یادداشت مترجم] برای توجیه هر هشدار. :عینک آفتابی:
و چرا این همه است؟
. به دلایل بسیاری. و CASE همه آنها را حذف نمی کند. اما با آن، شب ها با اعلان های بهتر از خواب بیدار می شوید. این روش فرآیندهای سازمانی مختلفی را پوشش می دهد که در این امر نیز کمک خواهد کرد.
زیبایی روش های RED و USE در این است که با کمک آنها نه تنها می دانیم چگونه کار کنیم، بلکه با هم به یک زبان صحبت می کنیم. امید من این است که روش CASE بحث درباره اعلان‌هایی که از سیستم‌های ما محافظت می‌کنند اما همکاران ما را مشغول نگه می‌دارند را آسان‌تر کند.
نکته این است که شما باید در سازمان خود فرهنگی ایجاد کنید که در آن اعلان ها با بی تفاوتی سالم برخورد شود. نوتیفیکیشن ها را می توان برای یک هدف خاص ایجاد کرد، اما این واقعیت نیست که بعداً ارزش خود را از دست ندهند. چرا این اعلان را تنظیم کردیم؟ چند وقت پیش معیارهای آن بازنگری شده است؟ با CASE می توان به این سوالات پاسخ داد.
Context-Heavy - اتصال متن
ساعت 3 صبح بهترین زمان برای خواندن پیام هایی نیست که حاوی کلمات هوشمند زیادی هستند. برای پاسخگویی موثر، به اطلاعات نیاز دارید. در حالت ایده‌آل، این باید اطلاعاتی در مورد یک موضوع خاص باشد، که زمینه آن بلافاصله روشن است و اعلان‌ها باید به گونه‌ای پیکربندی شوند که این امکان وجود داشته باشد. این "مشاهده" و "جهت گیری" از . خجالت آور نیست که وقت خود را صرف این تنظیمات کنید، زیرا حواس پرتی دائماً گرانتر است. بیایید به هم احترام بگذاریم.
مشکلات منابع زیادی دارند. مخصوصا ارواح
چگونه می توانم به افسر وظیفه کمک کنم؟ اولین چیزی که افسر وظیفه می بیند یک اعلان است، بنابراین همه فرضیه ها را بر اساس آن می سازد. سپس به دستورالعمل‌ها و داشبوردها نگاه می‌کند، اما آیا همیشه اطلاعاتی در مورد یک اعلان خاص وجود دارد و نه فقط اطلاعات عمومی؟ آلسپا توصیه می‌کند «درباره نحوه تفسیر یا پاسخ دادن به اعلان فکر کنید» (اسلاید 29). یک اعلان خوب بر روی شخص در حال انجام وظیفه متمرکز است، نه فقط با یک آستانه پیکربندی شده است.
بنابراین در اینجا چند ایده در مورد چگونگی بهبود زمینه اعلان وجود دارد:
- چیزی مفید و خاص به کاربر نشان دهید، و نه فقط دستورالعمل های معمولی یا داشبورد. قبلاً، من و بچه ها از داشبوردهای تحقیقی استفاده می کردیم که برای اعلان های خاص پیکربندی شده بودند. اگر مشکل شناخته شده باشد، این کمک خواهد کرد، اما فقط دیگران را سردرگم می کند. اینجا باید تعادل پیدا کنیم.
- در مورد تاریخچه اعلان به ما بگویید: آیا جدید است؟ آیا اغلب کار می کند؟ فصلی است؟
- نمایش تغییرات اخیر در وضعیت سیستم. آیا اخیراً چیزی تغییر کرده است؟ (به عنوان مثال، استقرار یا فعال/غیرفعال کردن عملکرد.)
- روابط را نشان دهید و اطلاعاتی را برای مدل ذهنی ارائه دهید: وابستگی‌های سیستم باید به وضوح قابل مشاهده باشند، ترجیحاً با نشان دادن عملکرد.
- به سرعت کاربر را با تیم مرتبط کنید: آیا آنها می توانند حوادث جاری را ببینند یا می توانند بفهمند که چه کسی در شرکت اعلان دریافت کرده است؟ برنامه فعال شد؟
در حالت ایده‌آل، یک برنامه مدیریت حادثه، توصیه‌هایی در مورد چگونگی بهبود زمینه اعلان بررسی‌های حادثه ارائه می‌دهد. همیشه چیزی برای کار کردن وجود دارد!
عملی - ارزش عملی
آیا افسر وظیفه باید در پاسخ به اطلاعیه کاری انجام دهد؟ اگر نیازی به انجام کاری ندارید یا معلوم نیست چه کاری باید انجام دهید، چرا او را بیدار کردید؟ باید از اعلان‌هایی که باعث آزار افراد در حال انجام وظیفه می‌شود و نیازی به اقدام ندارند، اجتناب کنید.
باید چکار کنم؟ چه چیزی می خواهید؟
در گذشته، زمانی که سیستم‌ها ساده و تیم‌ها کوچک بودند، ما نظارت را فقط برای اینکه در راس امور قرار بگیریم، راه‌اندازی می‌کردیم. اعلان اینکه بار روی پشته افزایش یافته است، اگر سرویس متعاقباً عملکرد نادرست داشته باشد، زمینه را به ما می دهد. در مقیاس بزرگ، چنین اعلان‌هایی فقط سردرگمی ایجاد می‌کنند، زیرا سیستم‌های ما همیشه در حالت تخریب با شدت متفاوت کار می‌کنند. این به سرعت منجر به و البته از دست دادن حساسیت. بنابراین افسر وظیفه چنین اطلاعیه هایی را نادیده می گیرد و یا حتی فیلتر می کند و همیشه در صورت نیاز به آنها پاسخ نمی دهد. در این دام نیفتید! همه اعلان ها را پشت سر هم تنظیم نکنید و سپس آنها را از طریق ایمیل به پوشه ای خداحافظی ارسال نکنید.
در اینجا یک اعلان با ارزش عملی به نظر می رسد:
- یک اعلان به جای گزارش صرف اخبار، نیاز به اقدام دارد.
- خودکار کردن این عمل دشوار یا خطرناک است. اگر می توان یک عمل را خودکار کرد، پس آن را خودکار کنید، از اذیت کردن مردم دست بردارید!
- این اطلاعیه حاوی توصیه های فوری در فرم است (SLA) یا (RTO). سپس افسر وظیفه می تواند برنامه مدیریت حوادث سازمان را فعال کند.
من می خواهم توضیح دهم: من نمی گویم که اعلان ها باید فقط برای مهم ترین SLO ها (اهداف سطح سرویس) برای API ارائه شوند. نظارت بر SLO به طور مداوم پراکنده و تقسیم شده است و به یک رویکرد یکسان برای همه خدمات نیاز دارد. واضح است که شما مهمترین SLOها را برای مشتریانی که به شما پول می دهند ردیابی خواهید کرد. اما SLO های زیرساخت مانند پایگاه های داده نیز نیاز به نظارت دارند. به زودی باید با مشتریان داخلی سر و کار داشته باشید و از آنها حمایت کنید. و غیره تا بی نهایت.
بر اساس علائم - تأکید بر علائم
شما چه بخواهید چه نخواهید، در یک سیستم توزیع شده (کاوج) کار می کنید.. در نتیجه، شما از تاکتیک های مختلفی برای جداسازی سرویس ها و محافظت از آنها در برابر شکست استفاده می کنید (Trainor et al.)3. و اگرچه جمع آوری زباله با تأخیر یا پرس و جو پایگاه داده متوقف شده نشان دهنده مشکلات است، اگر کاربران در آینده نزدیک با مشکل مواجه نشدند، نیازی به عجله برای رفع آنها نیست.
اینها سیگنال های مهمی هستند و ممکن است ارزش عملی داشته باشند، اما اگر مزاحمتی برای کاربران ایجاد نکنند، آنقدر فوری نیست که حواس متصدی را پرت کند. اعلان‌های مبتنی بر علت، تصاویری فوری از مدل‌های ذهنی ما در مورد خرابی سیستم هستند. بهتر است علائم مهم را دنبال کنید تا اینکه سعی کنید همه دلایل احتمالی یک شکست را فهرست کنید.
برای معنی دار کردن اعلان ها، روی آن تمرکز کنید ، برای کاربران مهم است. Evashchuk این را "نظارت برای کاربران" می نامد. به یاد داشته باشید که این فلسفه باید در سراسر سازمان اعمال شود. اگر سرویسی در جایی در عمق زیرساخت مشکلات فوری داشته باشد، تیم مربوطه از آنها مراقبت خواهد کرد. محافظت از سیستم ها در برابر چنین خرابی ها یک موضوع کاملاً مجزا است (Trainer و همکاران، بخش استراتژی هایی برای به حداقل رساندن وابستگی های بحرانی).
علائم آنقدرها متغیر نیستند
ریچارد کوک به ما یادآوری می کند که سیستم های پیچیده مملو از نقص ها، کاستی ها و مشکلات هستند. تلاش برای فهرست کردن همه دلایل ممکن یک کار سیزیفی است. شما سعی می کنید مشکلات را توصیف کنید، اما آنها همیشه تغییر می کنند. سیندی سریداران معتقد است که «نباید سیستم‌ها هر ثانیه در شرایط عالی باشند» و بهتر است از رویکرد انسانی‌تری استفاده کنیم. ("نظارت بر سیستم های توزیع شده")، 7).
از اطلاع رسانی پس از حادثه خودداری کنید
به طور معمول، اعلان‌های علل برای تصحیح حوادث پیکربندی می‌شوند. و این اعلان‌های محدود در مورد آنچه اتفاق افتاده است، احساس امنیت کاذبی ایجاد می‌کند، زیرا سیستم هر بار راه‌های جدیدی برای شکستن ارائه می‌کند.
فریب اعلامیه های علت را نخورید. بهتر است فکر کنید:
- چرا اعلان مبتنی بر علائم متوجه مشکل نشد؟
- آیا بهبود زمینه برای کاربر مفید خواهد بود؟
- چگونه می‌توان ابزارهای نظارت را برای تشخیص سریع‌تر به جای جمع‌آوری اعلان‌ها در مورد آنچه اتفاق افتاده، بهبود بخشید؟
ابزارهای نظارتی برای تشخیص تنها در صورتی به شما کمک می کند که به آنها به عنوان راهی برای حرکت از علامت به راه حل فکر کنید. بدون این بازخورد، شما به سادگی با اعلان‌ها و نمودارهای دیرهنگام درباره شکست‌های گذشته بمباران می‌شوید - و حتی کلمه‌ای در مورد شکست‌های آینده نیست. این یک فرصت عالی برای یک سازمان برای حرکت از دفاع به حمله است. و توسعه دهندگان و مدیران محصول همان انتظارات و اهداف روشن را خواهند داشت. مورد - CASE (:wink:) - برای هر اعلان مشخص است.
اعلان‌های مبتنی بر دلیل در حد اعتدال قابل تحمل هستند
گاهی اوقات سیستم ما از نظر اعلان های مبتنی بر علت، انتخاب کمی برای ما باقی می گذارد. و گاهی اوقات کسانی که در حال انجام وظیفه هستند به خوبی درک می کنند که یک علامت قطعاً منجر به شکست خواهد شد و بنابراین دارای ارزش عملی است. شاید شما فقط مطمئن نیستید که چه اتفاقی می‌افتد و اعلان‌ها را طوری تنظیم می‌کنید که در قسمت امن باشند. امیدواریم این اقدام موقتی باشد تا زمانی که بتوانیم سیستم را برای حل مشکل عملکرد تغییر دهیم.
هنگام برخورد با این شرایط، سایر اجزای CASE را در نظر داشته باشید. فقط به این دلیل که موقتی است به این معنی نیست که می توانید با سر خود فکر نکنید.
ارزیابی شده - ارزیابی
هر گونه تغییر در سیستم (کد جدید، زیرساخت جدید، هر چیز جدید) دامنه خرابی ها را گسترش می دهد (کوک، 3). آیا این اعلان همچنان مطابق انتظار کار می کند؟ مدل‌های ذهنی روشن و فعلی سیستم‌ها و تجربه پاسخگویی به برخی اعلان‌های پشتیبانی - اینها ویژگی های کلیدی هستند . نقص در سیستم ها به طور مداوم در حال تغییر است و ما باید با آنها همراه باشیم.
شما باید به طور مداوم کیفیت هر اعلان را ارزیابی کنید تا مطمئن شوید که مطابق انتظار کار می کند. رهبران عزیز! اگر به آنها کمک کنید این روند را ایجاد کنند، برای تیم های شما بسیار آسان تر خواهد بود! در اینجا چند ایده ارزیابی وجود دارد:
- استفاده کنید , یا سایر روش های تست اطلاع رسانی این تیم می تواند بدون نیاز به یک سیستم مدیریت حوادث سنگین این کار را انجام دهد!
- مجموعه ای از تمام اعلان های مربوط به حادثه را در برنامه مدیریت حادثه خود بگنجانید. مفید، مضر، نامناسب، نامشخص و غیره را علامت گذاری کنید. از آنها به عنوان بازخورد استفاده کنید.
- اعلان‌های مناسب به ندرت فعال می‌شوند و با دقت آزمایش می‌شوند. مطمئن شوید که همه پیوندها کار می کنند، به زمینه مناسب اشاره می کنند و غیره.
- اگر یک اعلان هرگز شلیک نمی‌شود یا خیلی مکرر فعال نمی‌شود، مشکلی در آن وجود دارد. آن را تعمیر یا حذف کنید. مراقب انفعال یا فعالیت بیش از حد باشید!
- مهرهای زمانی اعلان را با تاریخ انقضا تنظیم کنید. اگر تاریخ انقضا منقضی شده است، اعلان را با استفاده از روش CASE ارزیابی کنید و مهر زمانی را به روز کنید. درست مانند غذا، تاریخ انقضا را به طور مرتب بررسی کنید.
- فرآیند بهبود اعلان ها را ساده کنید. از نظارت به عنوان کد استفاده کنید و اعلان‌ها را در یک مخزن Git ذخیره کنید. درخواست‌های کششی به تعامل تیم کمک می‌کنند و سابقه اعلان‌های گذشته را به شما می‌دهند. و دیگر از تغییر نوتیفیکیشن ها یا درخواست اجازه از مسئولین آنها ترسی نخواهید داشت.
- بازخورد را برای اعلان‌ها تنظیم کنید، حتی اگر ساده باشد ، به طوری که افسران وظیفه اطلاعیه ها را به عنوان بی فایده یا مزاحم علامت گذاری می کنند. پیوند یا فراخوان اقدام را در خود اعلان جاسازی کنید و بازخورد خود را مرتباً بررسی کنید.
- یک قانون را در تیم ایجاد کنید - اجازه دهید کسانی که وظیفه دارند کار کنند تا وقتی کار کمی وجود دارد، وظیفه را ساده کنند. باشد که همه چیز بعد از شما کمی بهتر از قبل شود.
نتیجه
من معتقدم روش CASE به توسعه دهندگان و سازمان ها کمک می کند تا درباره راه اندازی و ارسال اعلان های خودکار بحث کنند. یک توسعه‌دهنده می‌تواند با استفاده از روش CASE ارزیابی اعلان‌ها را آغاز کند و سپس کل سازمان با سایر توسعه‌دهندگان، مدیریت و برنامه‌های مدیریت رویداد همراه شود تا اعلان‌ها را در شکل خوبی نگه دارد. این به هیچ ابزار خاصی یا فرآیندهای پیچیده نیاز ندارد.
کل صنعت باید در حین انجام وظیفه به فاکتور انسانی فکر کند بدون اینکه خدمات مشتری درجه یک را قربانی کند. همه این ابزارها و شیوه ها را می توان و باید بهبود بخشید. امیدوارم روش CASE به این امر کمک کند.
از اعلان های بهبودیافته لذت ببرید!
منبع: www.habr.com