چطور صفحه وضعیت بسازیم: کامپوننت‌ها، خرابی‌ها و بررسی آپتایم

صفحه وضعیت به کاربرانتان در یک جا می‌گوید سرویس شما کار می‌کند یا نه. برای ساختنش به فهرستی از کامپوننت‌ها (وب‌سایت، API، پرداخت، ارسال ایمیل)، وضعیت فعلی هر کدام، خرابی‌های دارای به‌روزرسانی زمان‌دار، تاریخچه خرابی‌های گذشته و در صورت تمایل اشتراک نیاز دارید تا مردم بدون بررسی دستی از مشکلات مطلع شوند. خود صفحه ساده است. تصمیم مهم این است که کجا اجرا شود: صفحه وضعیت باید وقتی اپ شما از کار افتاده بالا بماند، پس نباید میزبانی، پایگاه‌داده یا خط انتشارش را با چیزی که گزارش می‌دهد به اشتراک بگذارد.

صفحه وضعیت برای چیست؟

وقتی چیزی خراب می‌شود، کاربران سه چیز می‌خواهند بدانند: آیا فقط من مشکل دارم، آیا شما خبردار هستید و کی درست می‌شود. صفحه وضعیت به هر سه پاسخ می‌دهد، بدون سیلی از تیکت‌های پشتیبانی. همچنین با گذر زمان اعتماد می‌سازد، چون تاریخچه خرابی‌های قابل‌دیدن و گزارش‌های صادقانه نشان می‌دهد با مشکلات چطور برخورد می‌کنید.

این صفحه تاریخچه تغییرات نیست. ویژگی‌های جدید در صفحه تغییرات می‌روند؛ قطعی‌ها و نگهداری‌ها اینجا.

صفحه به چه چیزهایی نیاز دارد

داده

وضعیت کامپوننت‌ها معمولاً فهرست ثابت و کوتاهی است: عملیاتی، افت عملکرد، قطعی جزئی، قطعی کامل، در حال نگهداری.

صفحه‌ها

• صفحه عمومی وضعیت: بنر کلی (مثلاً «همه سیستم‌ها عملیاتی‌اند» یا بدترین وضعیت فعلی)، هر کامپوننت با وضعیتش، هر خرابی فعال با به‌روزرسانی‌هایش، نگهداری‌های پیش رو و در صورت داشتن داده پایش، یک نوار تاریخچه ۹۰ روزه.
• صفحه خرابی: خط زمانی کامل به‌روزرسانی‌های یک خرابی، با نشانی اختصاصی تا پشتیبانی بتواند به آن لینک بدهد.
• تاریخچه: خرابی‌های گذشته به تفکیک ماه.
• اشتراک: ثبت‌نام با ایمیل همراه تأیید و تنظیمات جدا برای هر کامپوننت.
• مدیریت: ایجاد خرابی، ثبت به‌روزرسانی، تغییر وضعیت کامپوننت‌ها و برنامه‌ریزی نگهداری.

دسترسی‌ها

عموم مردم هر چیزی را که منتشر شده می‌بینند. فقط تیم شما می‌تواند ارسال کند. اگر بشود، ورود مدیریت را از سیستم ورود اپ اصلی جدا نگه دارید تا قطعی سرویس احراز هویت شما را از صفحه وضعیت خودتان بیرون نگذارد.

تصمیم کلیدی: آن را مستقل نگه دارید

اینجاست که بیشتر صفحه‌های وضعیت خانگی شکست می‌خورند. اگر صفحه وضعیت شما:

• روی همان سرور یا حساب میزبانی اپ اجرا شود،
• از همان پایگاه‌داده بخواند،
• پشت همان تنظیمات دامنه یا CDN باشد،
• یا با همان خط انتشار مستقر شود،

آنگاه خیلی از قطعی‌ها آن را هم از کار می‌اندازند، دقیقاً وقتی که مردم به آن نیاز دارند. گام‌های عملی:

• میزبانی جدا. پروژه یا ارائه‌دهنده‌ای متفاوت از اپ اصلی.
• ساب‌دامین اختصاصی، مثل status.example.com که جداگانه در DNS تنظیم شده. نحوه کار دامنه‌ها و DNS را ببینید.
• داده مستقل. خرابی‌ها در فضای ذخیره‌سازی خود صفحه وضعیت نگهداری شوند، نه در پایگاه‌داده اپ.
• پشتیبان ایستا. برخی تیم‌ها صفحه عمومی را ایستا می‌سازند و با هر به‌روزرسانی دوباره تولیدش می‌کنند، پس تقریباً چیزی برای خراب شدن نیست.

به‌روزرسانی دستی یا بررسی خودکار

دستی (از اینجا شروع کنید)

تیم شما خرابی‌ها را ثبت می‌کند و وضعیت کامپوننت‌ها را از صفحه مدیریت دستی تغییر می‌دهد. در عمل بسیاری از صفحه‌های وضعیت همین‌طور کار می‌کنند، چون قضاوت انسانی («پرداخت برای برخی نوع کارت‌ها کند است») مفیدتر از یک نقطه قرمز خودکار است.

برای اینکه سریع از مشکلات باخبر شوید، از یک ابزار پایش آپتایم بیرونی استفاده کنید که هر یک دقیقه یا کمی بیشتر اپ شما را بررسی کند و از طریق ایمیل، پیامک یا چت هشدار دهد. بسیاری از سرویس‌های پایش سطح رایگان دارند.

خودکار

خودکارسازی یعنی چیزی به‌طور منظم هر کامپوننت را بررسی کند و وضعیتش را به‌روز کند. این به کدی نیاز دارد که بیرون از زیرساخت اصلی اپ شما و طبق زمان‌بندی اجرا شود. دو الگوی رایج:

• یک پایشگر بیرونی، صفحه وضعیت شما را از طریق وب‌هوک فراخوانی کند وقتی بررسی‌ای شکست می‌خورد یا برمی‌گردد، و صفحه وضعیت کامپوننت را به‌روز کند.
• یک کار زمان‌بندی‌شده در همان میزبانی صفحه وضعیت که هر کامپوننت را پینگ می‌کند و نتیجه را ثبت می‌کند. پیش از تکیه بر این، بررسی کنید میزبانی‌تان با کارهای زمان‌بندی‌شده چطور کار می‌کند؛ راهنمای ما درباره اجرای کارهای پس‌زمینه گزینه‌ها را توضیح می‌دهد.

تغییرات خودکار می‌توانند در شبکه کند بین بالا و پایین بپرند. پیش از تغییر وضعیت، دو یا سه شکست پیاپی لازم کنید و برای قطعی بزرگ، اجازه دهید یک انسان تأیید کند.

نوشتن به‌روزرسانی‌های خرابی

• زود ثبت کنید. «در حال بررسی گزارش‌های ناموفق بودن ورود هستیم» در چند دقیقه بهتر از یک پیام کامل یک ساعت بعد است.
• بگویید کاربر چه چیزی را حس می‌کند، نه اینکه داخلی چه چیزی خراب شد.
• زمان به‌روزرسانی بعدی را قول بدهید و سر وقت آن را بدهید.
• پس از حل، یک خلاصه کوتاه بنویسید: چه شد، چقدر طول کشید و چه چیزی را تغییر می‌دهید.

یک پرامپت اولیه که کار می‌کند

یک صفحه وضعیت مستقل برای اپ ما به نام Parcelio بسازید که جدا روی status.parcelio.com میزبانی شود. کامپوننت‌ها: وب‌سایت، API ردیابی، اعلان‌ها، پرداخت، هرکدام با یکی از وضعیت‌های عملیاتی، افت عملکرد، قطعی جزئی، قطعی کامل یا در حال نگهداری. صفحه عمومی یک بنر کلی با بدترین وضعیت فعلی نشان بدهد، هر کامپوننت با وضعیتش، خرابی‌های فعال با به‌روزرسانی‌های زمان‌دار و جدیدترین اول، نگهداری‌های پیش رو و فهرست خرابی‌های گذشته به تفکیک ماه. هر خرابی صفحه اختصاصی خودش را داشته باشد. یک صفحه مدیریت با رمز عبور برای ایجاد خرابی (عنوان، میزان تأثیر، کامپوننت‌های تحت تأثیر)، ثبت به‌روزرسانی (پیام و وضعیت: در حال بررسی، شناسایی‌شده، در حال پایش، حل‌شده)، تغییر وضعیت کامپوننت‌ها و برنامه‌ریزی نگهداری اضافه کنید. یک نقطه پایانی POST به نام /api/check-result بسازید که نام کامپوننت و بالا/پایین بودن را از یک پایشگر بیرونی بگیرد، با یک توکن مخفی محافظت شود و کامپوننت را فقط بعد از سه شکست پیاپی به «افت عملکرد» ببرد. همه‌چیز را در پایگاه‌داده خود همین اپ ذخیره کنید. طراحی ساده و آرام که روی موبایل سریع لود شود.

مراحل ساخت

1. صفحه عمومی و مدیریت با خرابی‌های دستی. همین به‌تنهایی یک صفحه وضعیت کارآمد است.
2. میزبانی جدا و وصل کردن یک ساب‌دامین به آن.
3. صفحه‌های خرابی و تاریخچه.
4. پنجره‌های نگهداری.
5. اشتراک‌ها. ثبت‌نام ایمیلی با تأیید دوبار و اعلان برای خرابی‌ها و به‌روزرسانی‌های جدید. ایمیل به یک ارائه‌دهنده نیاز دارد؛ به نحوه ارسال ایمیل از اپ مراجعه کنید.
6. وب‌هوک پایشگر اگر تغییرات وضعیت خودکار می‌خواهید.
7. تمرین اجرا کنید. یک خرابی ساختگی بسازید، به‌روزرسانی ثبت کنید، حلش کنید، ایمیل‌ها را بررسی کنید و بعد حذفش کنید.

اشتباهات رایج

• میزبانی همراه اپ. رایج‌ترین و جدی‌ترین اشتباه.
• صفحه‌ای که همیشه «همه سیستم‌ها عملیاتی‌اند» می‌گوید. اگر هرگز مشکلی نشان ندهد، کاربران به آن اعتماد نمی‌کنند.
• بدون زمان‌بندی یا منطقه زمانی. زمان‌ها را همیشه همراه منطقه زمانی نشان دهید.
• تکیه بر ورود اپ اصلی برای صفحه مدیریت.
• سکوت بین به‌روزرسانی‌ها. «بدون تغییر، هنوز در حال کار هستیم» یک به‌روزرسانی معتبر است.
• نوسان وضعیت‌های خودکار. پیش از تغییر، شکست‌های تکراری لازم کنید.

کی یک سرویس آماده صفحه وضعیت بهتر است؟

سرویس‌های آماده صفحه وضعیت دقیقاً برای مشکل استقلال ساخته شده‌اند: روی زیرساخت جدا اجرا می‌شوند، اعلان اشتراک را با ایمیل و پیامک مدیریت می‌کنند و اغلب پایش و یکپارچگی با ابزارهای مدیریت خرابی را هم دارند. اگر آپتایم بخشی از چیزی است که مشتری‌ها پول می‌دهند، یا تعهد قراردادی برای گزارش خرابی‌ها دارید، یک سرویس اختصاصی معمولاً ارزشش را دارد. بسیاری برای تیم‌های کوچک سطح رایگان یا کم‌هزینه دارند، پس پیش از ساختن بررسی کنید.

خودتان بسازید وقتی می‌خواهید کنترل کامل طراحی و متن داشته باشید، نیازهایتان ساده است (چند کامپوننت و به‌روزرسانی دستی)، یا صفحه وضعیت بخشی از محصولی است که برای دیگران می‌سازید.

ساخت آن با Mythex

در Mythex می‌توانید صفحه وضعیت را به‌عنوان پروژه‌ای جدا از اپ اصلی بسازید، که میزبانی جدا و پایگاه‌داده خودش را دارد. آن را در چت توصیف کنید، در پیش‌نمایش زنده بررسی کنید، سپس منتشرش کنید و یک ساب‌دامین مثل status.yourdomain.com وصل کنید (دامنه سفارشی در طرح Pro است). در نظر داشته باشید اپ‌های منتشرشده در Mythex و پایگاه‌دادهٔ آن‌ها وقتی بی‌کار باشند به خواب می‌روند و با بازدید بعدی بیدار می‌شوند، پس بارگذاری اول بعد از یک دوره آرام ممکن است کندتر باشد؛ یک صفحه ساده و سبک کمک می‌کند.

Mythex کارهای زمان‌بندی‌شده را مستند نکرده، پس برای بررسی‌های خودکار از یک ابزار پایش آپتایم بیرونی استفاده کنید که یک نقطه پایانی وب‌هوک در صفحه وضعیت را فراخوانی کند (به دستورالعمل وب‌هوک مراجعه کنید). ایمیل‌های هشدار به مشترکان از طریق ارائه‌دهنده خودتان می‌روند، با کلید ذخیره‌شده به‌عنوان راز پروژه (دستورالعمل ارسال ایمیل).

پرسش‌ها