خواه وبلاگی با موضوع اجتماعی و خواه یک فروشگاه آنلاین معتبر داشته باشیم، Downtime یا به عبارتی «از دسترس خارج شدن سایت» می‌تواند هزینه‌های گزافی را به ما تحمیل کند که در همین راستا در این مقاله قصد داریم به بررسی این مقوله و همچنین فرمول محاسبهٔ هزینه‌های مربوطه بپردازیم.
Downtime چیست؟
دَون‌تایم در فضای وب، که نقطهٔ مقابل Uptime قرار دارد، به زمانی گفته می‌شود که یک سرور یا سایت در دسترس نیست و طبق روال معمول نمی‌تواند عملکرد طبیعی خود را دنبال کند (Outage اصطلاح دیگری که معادل Downtime محسوب می‌گردد.) از جمله دلایل رایجی که میتوانند منجر به از دسترس خارج شدن یک سرویس آنلاین شوند می‌شود به آپدیت اپلیکیشن/سرور، باگ‌های نرم‌افزاری، خطای انسانی، حملات سایبری و مشکلات سخت‌افزاری اشاره کرد. به جزو مورد اول (پروسهٔ آپدیت) که به صورت برنامه‌ریزی‌شده صورت می‌گیرد، الباقی دلایل فوق‌الذکر معمولاً از کنترل خارج هستند. اساساً دلایل مختلفی می‌تواند منجر به دَون‌تایم به صورت برنامه‌ریزی‌شده گردد که برخی از آنها عبارتند از:
- آپدیت/آپگرید سرور
- تعمیرات سخت‌افزاری
- تغییرات در تنظیمات پیکربندی
- رفع باگ‌های نرم‌افزاری
- دیپلوی نسخهٔ جدید اپلیکیشن
چگونه می‌توانیم هزینه‌های مرتبط با Downtime را محاسبه نماییم؟
پیش از این اشاره کردیم که دَون‌تایم برای کسب‌وکارهای آنلاین مساوی است با ضررهای مالی و نیاز به توضیح نیست که هرچه کسب‌وکاری گسترده‌تر باشد و کاربران بیشتری داشته باشد، در زمان دَون‌تایم ضررهای بیشتری را متحمل خواهد شد.
به منظور درک بهتر این موضوع، فرض کنیم یک فروشگاه آنلاین داریم که بنا به یکی از دلایل فوق از دسترس کاربران خارج می‌شود. در چنین مواقعی، Revenue (درآمد) کسب‌وکارمان به محض از دسترس خارج شدن سایت نیز قطع می‌گردد که از این پس این مؤلفه را با R می‌شناسیم (لازم به یادآوری است که مؤلفهٔ R در دیگر کسب‌وکارهای آنلاین همچون سایت‌های محتوا-محور با از دست رفتن درآمدی که از طریق تبلیغات، اشتراک و ... به دست می‌آید مرتبط خواهد بود.)
مسلماً وقتی یک کسب‌وکار آنلاین دَون‌تایم را تجربه می‌کند، تک‌تک اعضای تیم فنی درگیر این مشکل خواهند شد و از همین روی مؤلفهٔ دیگر را T که برگرفته از حرف اول Team است در نظر می‌گیریم. گرچه در چنین مواقعی بیشترین فشار روی دولوپرها و متخصصین دوآپس است، اما دیگر اعضای تیم همچون کارشناسان پشتیبانی از مشتریان، روابط عمومی و غیره نیز تا زمانی که سایت اصطلاحاً Up نشود درگیر مشتریان خواهند بود که همین مسئله تأثیرگذاری مؤلفهٔ T در محاسبهٔ کلِ هزینهٔ ناشی از دَون‌تایم را دوچندان می‌سازد.
برخی کسب‌وکارها، همچون شرکت‌های ارائه‌دهندهٔ خدمات ابری، هستند که مدل کسب‌وکارشان اصطلاحاً B2B است به این معنی که کاربران آنها خود شرکت‌های بزرگی هستند که سودآوری آنها ارتباط مستقیمی با شرکت مذکور دارد و این در حالی است که هرگونه دَون‌تایم باعث می‌گردد تا شرکت‌های زیرمجموعه نیز متحمل ضرر مالی شوند که از همین روی، مؤلفهٔ بعدی را C برگرفته از واژهٔ Customer در نظر می‌گیریم. در چنین بیزینس‌هایی معمولاً قراردادهایی تحت عنوان Service-Level Agreement یا به اختصار SLA بسته می‌شود به طوری که گاهی حتی یک دقیقه دَون‌تایم مساوی است با ضررهای هنگفت که جهت آشنایی بیشتر با مفهوم SLA می‌توانید به مقالهٔ SLI | SLA | SLO: مفاهیم مرتبط با SRE که باید با آنها آشنا بود مراجعه نمایید.
گاهی اوقات هزینه‌های غیرمستقیم دیگری نیز پس از دَون‌تایم متحمل می‌شویم که دسته‌بندی خاصی نمی‌توان برای‌شان در نظر گرفت که این مؤلفه را تحت عنوان M برگرفته از واژهٔ Miscellaneous منظور می‌کنیم. با این توضیحات، فرمول محاسبهٔ Cost of Downtime یا به عبارتی «هزینهٔ از دسترس خارج شدن» به صورت زیر خواهد بود:
Cost of Downtime = R + T + C + Mلازم به یادآوری است چنانچه دَون‌تایم در موقعیت‌های خاصی همچون کمپین‌های تبلیغاتی، بِلک فِرایدی و ... صورت گیرد، تک‌تک اِلِمان‌های فوق به صورت تصاعدی افزایش خواهند یافت که برآیند آنها مساوی است با ضررهای مالی هنگفتی که گاهی حتی دور از انتظار هستند!
ضررهای نامشهود Downtime
پیش از این گفتیم که مؤلفهٔ M به مسائلی مربوط می‌شود که معمولاً در دستهٔ خاصی قرار نگرفته اما نکتهٔ مهم اینجا است که نامشهود هستند و از آن جمله می‌توان به از دست رفتن دیتا، ضربه خوردن به برند شرکت، از دست دادن کاربران و ... اشاره کرد. به بیان بهتر، چنانچه در میان مشتریان سرویس آنلاین ما کسانی باشند که در فضای مجازی تحت عنوان سلبریتی شناخته می‌شوند و ایشان در شبکه‌های اجتماعی شروع به گله و شکایت از برندمان کنند، به سادگی میتوانند بسیاری از مشتریان بالقوه را از مراجعه به سایت‌مان منصرف کنند مضاف بر اینکه خودشان نیز ممکن است به سَمت رقبا کشیده شوند.
آیا می‌توان Downtime را به صفر رساند؟
پاسخ کوتاه به چنین پرسشی خیر است اما در عین حال می‌توان تا حد ممکن جلوی آن را گرفت. امروزه با فراگیر شدن فناوری کلود از یکسو و همچنین میزبانی وب اپلیکیشن‌ها در دیتاسنترهای مختلف از سوی دیگر، مدیریت سرویس‌های آنلاین به مراتب پیچیده‌تر از گذشته شده و اینجا است که پای Chaos Engineering به میان می‌آید.
در حقیقت، ایدهٔ Chaos Engineering از آنجا ناشی می‌شود که این امکان در اختیار تیم‌های مهندسی نرم‌افزار قرار می‌گیرد تا در کنار شیوه‌های مدرن توسعهٔ نرم‌افزار، دوآپس، یونیت تست و غیره و پیش از تجربهٔ هرگونه دَون‌تایمی، تک‌تک بخش‌های اپلیکیشن را زیر بار (استرس) قرار داده تا در نهایت بتوانند نقاط ضعف احتمالی را کشف کنند (برای کسب اطلاعات بیشتر، می‌توانید به مقالهٔ Chaos Engineering چیست؟ مراجعه نمایید.)
یکی از ابزارهای اپن‌سورس در این رابطه Chaos Monkey نام دارد که توسط کمپانی نت‌فلیکس عرضه شده است که جهت آشنایی بیشتر می‌توانید به مقالهٔ Chaos Monkey: ابزاری اپن‌سورس جهت تست نرم‌افزار مراجعه نمایید.
