(این نوشته پیش‌تر به شکل رشته توییت نوشته شده بوده و سپس در ویرگول رونوشت شده)
اگر برای سرویستون پایش و هشدار (monitoring & alerting) انجام می‌دید شاید این گفتار به دردتون بخوره. از تیم‌هایی که روی هم سرویس فعلی ما رو می‌سازن، برخی‌ها هم یک نیروی حاضریراق (oncall) از تیم توسعه‌دهنده (dev) دارن و هم یکی از SRE (سرویس‌های حیاتی‌تر و پیچیده‌تر)، برخی فقط SRE و برخی فقط dev. همه جورش، ذیل یک سرویس مادر یکسان، هست. سرویس دیگر (CDN) که کوچک‌تر بود هم، هم SRE حاضریراق داشت و هم dev. برخی هشدارها به این گروه می‌ره و برخی به اون. دربسیاری مواقع، این دو همدیگر رو (یا تیم‌های دیگر رو) فرامی‌خونن.
این جزییات رو برای این می‌گم که نقش SRE اخیرا در بازار ایران پررنگ شده و درباره‌ش می‌پرسن. طبیعتا کاری که ما می‌کنیم مرجع نیست، هدف فقط دادن داده‌ی پراکنده هست.
هنگام یک outage غیربدیهی معمولا نماینده‌های چندین تیم (از جمله رهبران فنی اگر نصف شب نباشه، نه فقط شخص حاضریراق فعلی که شاید تازه‌کار باشه) به گروه پاسخ میان و هم‌کاری می‌کنن، در چارچوب یک پروتکل ساده‌ی پاسخ به حادثه (incident response roles) برای جلوگیری از دور خود چرخیدن.
این کار ممکنه چند دقیقه یا چند روز طول بکشه - بسته به پیچیدگی سیستم و outage. توصیه می‌شه اشخاص پس از چند ساعت جایگزین بشن و یک ماراتن طولانی پای خط پاسخ و debug نباشن تحت آدرنالین. به ویژه SREها خوب اینو رعایت می‌کنن. devهای نکرده، پشیمونن. راستش پاسخ به حادثه به نوعی جذابه.
شاید مهم‌ترین بخش: هنگام هشدار، یک اشتباه شایع، آغاز به «ریشه‌یابی» توسط پاسخ‌دهنده‌ست ولی نخستین گام باید بررسی شدت (impact) حادثه و درجه‌دهی باشه، سپس تسکین (mitigation) یا اصطلاحا جلوگیری از خون‌ریزی (مثلا برگردوندن اجزای سیستم به حالت پیشین یا دور کردن بار از محدوده‌ی تحت تاثیر)، و در نهایت «ریشه‌یابی». البته در برخی موارد گزینه‌های موجود برای تسکین، مشکل رو حل نمی‌کنه و دو گام آخر ترکیب می‌شه که معمولا یکی کار dev و دیگری کار SREهاست و معمولا همین موارده که به چند ساعت و چند روز می‌رسه.
پی‌نوشت: هشدار (alert) هایی که در پی‌شون، شخص حاضریراق (oncall) باید یک کارِ روتین انجام بده، مثلا فلان چیزو restart/delete/disable کنه، تقریبا بدترین استفاده از سیستم هشداره. اگر یک کاری می‌تونه به طور خودکار تشخیص و انجام داده بشه باید بشه، نه با فراخوندن نیروی انسانی. داشتن oncall به خودی خود ارزش نیست. وقتی ظرفیت oncall با چنین تمیزسازی‌هایی خلوت شد، می‌شه رفت سراغ لایه‌های بالاتر در «نگه‌داری سرویس». بخشی از کار SRE همینه: طراحی نرم‌افزار برای کاهش رنج (toil) و رفتن به لایه‌ی بعدی، نه فقط پاسخ به هشدار.
(بخش دوم این یادداشت: این‌جا.)
