بخش بزرگی از کاری که در آویاتو انجام میدهیم، قرار نیست دیده شود. کاربر وارد پنل میشود، ماشین مجازیاش را میبیند، به سرور متصل میشود، سایت یا سرویسش را اجرا میکند و بعد به سراغ کار اصلی خودش میرود. اگر همهچیز درست کار کند، معمولاً دلیلی ندارد به شبکه، فضای ذخیرهسازی، مجازیساز، مسیریابی یا سرور فیزیکی پشت آن فکر کند. اینها باید آرام و بیصدا در پسزمینه بمانند، درست مانند سیمهای برق داخل دیوار که تا وقتی چراغ روشن است، کسی حضورشان را به یاد نمیآورد.
این اتفاق خوبی است. زیرساخت وقتی وظیفهاش را درست انجام میدهد، خودش را از مسیر کاربر کنار میکشد. قرار نیست هر روز حضورش را یادآوری کند یا برای دیده شدن کاری انجام بدهد. قرار است قابل پیشبینی باشد، بیدردسر کار کند و اجازه بدهد آدمها به چیزهایی فکر کنند که واقعاً برایشان مهم است. مشتری آویاتو معمولاً نمیخواهد وقتش را صرف فکر کردن به سرور کند. او میخواهد یک وبسایت راه بیندازد، نرمافزاری را اجرا کند، محصولی بسازد، دیتابیسی را زنده نگه دارد یا بخشی از کسبوکارش را آنلاین نگه دارد. ماشین مجازی برای او مقصد نیست؛ راهی است برای رسیدن به مقصد.
وقتی همهچیز سالم است، این راه تقریباً ناپدید میشود. کسی هر چند دقیقه یک بار وارد پنل نمیشود تا مطمئن شود دیسک هنوز کار میکند یا مسیرهای شبکه سر جای خودشان هستند. نباید هم لازم باشد چنین کاری انجام دهد. کاربر باید بتواند وجود لایههای فنی زیر محصولش را فراموش کند و مطمئن باشد چیزی که دیروز کار میکرد، امروز هم همانطور کار خواهد کرد. شاید یکی از عجیبترین ویژگیهای کار در زیرساخت همین باشد: هرچه بهتر کار کنیم، کمتر دیده میشویم.
اما کافی است یک سرویس برای چند دقیقه از دسترس خارج شود. در همان لحظه، چیزی که تا چند دقیقه قبل تقریباً نامرئی بود، به مهمترین بخش ماجرا تبدیل میشود. کاربر دیگر فقط سایت یا نرمافزار خودش را نمیبیند. حالا به سرور، شبکه، آیپی، پنل، فضای ذخیرهسازی و پشتیبانی فکر میکند. چیزی که قرار بود در پشت صحنه بماند، ناگهان به وسط صحنه میآید و همهی نگاهها به آن دوخته میشود.
ممکن است مشکل کوچک باشد. شاید یک سرویس داخل ماشین متوقف شده باشد، فضای دیسک پر شده باشد، تنظیمی تغییر کرده باشد یا مصرف منابع از حد معمول بالاتر رفته باشد. شاید هم مسئله در جایی از زیرساخت باشد که کاربر هیچ دسترسی مستقیمی به آن ندارد. اما از نگاه او، نتیجه در ابتدا ساده است: چیزی که باید کار میکرد، دیگر کار نمیکند. صفحهای باز نمیشود، اتصال برقرار نمیشود یا درخواستها بیپاسخ میمانند. پشت همین نشانهی ساده، گاهی مسیر بلندی برای پیدا کردن علت وجود دارد.
در سمت زیرساخت، یک صفحهی بازنشده میتواند دهها دلیل مختلف داشته باشد. ممکن است ماشین روشن باشد اما سیستمعامل پاسخ ندهد. ممکن است شبکه داخل ماشین اشتباه تنظیم شده باشد. شاید یک فرایند تمام حافظه را گرفته باشد یا یک بخش از مسیر ارتباطی دچار مشکل شده باشد. پیدا کردن پاسخ همیشه با اولین نگاه ممکن نیست و همینجا است که آرام ماندن اهمیت پیدا میکند. در زمان اختلال، وسوسهی بزرگی وجود دارد که چند تغییر را همزمان انجام بدهیم، شاید یکی از آنها مشکل را حل کند. اما هر تغییر عجولانه میتواند رد علت اصلی را محو کند یا مسئلهی تازهای بسازد.
بخشی از کار زیرساخت، تصمیم گرفتن در زمانی است که هر دقیقه طولانیتر از معمول به نظر میرسد. سرعت مهم است، اما شتابزدگی نه. باید بتوانیم میان این دو تفاوت بگذاریم. وقتی سرویس دیگران به تصمیمهای ما وابسته است، آرامش نوعی بیخیالی نیست؛ بخشی از مسئولیت است. باید بدانیم چه چیزی را تغییر میدهیم، چرا تغییر میدهیم و اگر نتیجه آن چیزی نبود که انتظار داشتیم، چطور به نقطهی قبل برگردیم.
هیچ سیستم فنیای را نمیتوان طوری ساخت که هرگز دچار مشکل نشود. سختافزار ممکن است خراب شود، نرمافزار ممکن است باگ داشته باشد، تنظیمات ممکن است اشتباه باشند و تغییر کوچکی که بیخطر به نظر میرسد، نتیجهای پیشبینینشده داشته باشد. اعتمادپذیری به این معنی نیست که وانمود کنیم هیچ اتفاقی نمیافتد. معنای واقعی آن این است که برای روزی که اتفاقی میافتد، آماده باشیم.
این آمادگی در چیزهای کوچکی ساخته میشود که بیشتر وقتها دیده نمیشوند. در هشدارهایی که قبل از پر شدن دیسک ارسال میشوند، در بررسیهایی که پیش از تبدیل شدن یک نشانهی کوچک به یک مشکل بزرگ انجام میشوند، در بکاپی که فقط ساخته نشده و واقعاً قابل بازیابی است، در ثبت تغییراتی که کمک میکند بفهمیم چه چیزی عوض شده و در ارتباطی که هنگام اختلال با کاربر قطع نمیشود. کاربر همیشه انتظار ندارد همهچیز در چند ثانیه حل شود، اما حق دارد بداند مسئله دیده شده، در حال بررسی است و چه چیزی قرار است بعد از آن اتفاق بیفتد.
گاهی یک توضیح ساده و روشن، از چند پیام فنی ارزشمندتر است. وقتی کسی نمیتواند به سرویسش دسترسی پیدا کند، عبارتی مبهم مثل «خطای داخلی» چیزی به او اضافه نمیکند. شفافیت همیشه به معنی توضیح تمام جزئیات فنی نیست. گاهی فقط یعنی صادقانه بگوییم مشکل وجود دارد، محدودهی آن را میدانیم یا هنوز در حال پیدا کردن علت هستیم. پنهان کردن پیچیدگی، با پنهان کردن واقعیت فرق دارد.
بخش زیادی از پیچیدگی زیرساخت باید پشت محصول باقی بماند. کاربر نباید برای ساخت یک ماشین مجازی، معماری شبکهی دیتاسنتر را بشناسد. نباید برای ارتقای منابع، دربارهی ساختار دیسکها تصمیم بگیرد یا برای روشن و خاموش کردن یک سرور، با جزئیات مجازیساز درگیر شود. وظیفهی ما این است که این پیچیدگیها را مدیریت کنیم و فقط آن بخشی را نشان بدهیم که برای تصمیمگیری لازم است. اما یک محصول ساده، محصولی نیست که واقعیت را حذف کند. محصولی است که واقعیت را به شکل قابل فهمتری نشان بدهد.
بیشتر کارهای نگهداری زیرساخت خروجی چشمگیری ندارند. بررسی وضعیت دیسکها، اصلاح یک تنظیم، آزمایش بازیابی بکاپ، پیدا کردن علت یک خطای پراکنده یا تغییر کوچکی در مانیتورینگ، چیزهایی نیستند که بتوان هر بار برایشان یک خبر بزرگ منتشر کرد. با این حال، روزهای آرام از همین کارهای کوچک ساخته میشوند. گاهی موفقترین تغییری که در زیرساخت انجام میدهیم، تغییری است که باعث میشود هیچ اتفاقی نیفتد.
یک هشدار پیش از آنکه سرویس از دسترس خارج شود ارسال میشود. یک قطعه قبل از خرابی کامل تعویض میشود. یک تنظیم اشتباه پیش از آنکه به مشتری آسیب بزند اصلاح میشود. اینها لحظههای درخشانی برای نمایش ندارند، اما چیزی که کاربران آن را پایداری مینامند، تا حد زیادی از همین لحظههای دیدهنشده ساخته شده است. اعتماد معمولاً در یک حرکت بزرگ به وجود نمیآید. آرام و تدریجی، از تکرار روزهایی ساخته میشود که همهچیز همانطور که باید کار میکند.
وقتی مشکلی برطرف میشود و سرویس دوباره در دسترس قرار میگیرد، مهمترین بخش کار انجام شده، اما ماجرا هنوز تمام نشده است. باید بفهمیم دقیقاً چه اتفاقی افتاد. آیا نشانهای وجود داشت که زودتر متوجه آن نشدیم؟ آیا هشدار مناسبی نداشتیم؟ آیا فرایند بازیابی بیش از حد طول کشید؟ آیا پیام داخل پنل میتوانست واضحتر باشد؟ آیا کاری هست که دفعهی بعد بتوانیم بهتر، سریعتر یا مطمئنتر انجام بدهیم؟
اگر فقط سرویس را برگردانیم و از کنار علت عبور کنیم، همان مشکل ممکن است دوباره برگردد. هر اختلال، علاوه بر اینکه مسئلهای برای حل کردن است، تصویری از نقاط ضعیف سیستم به ما نشان میدهد؛ نقاطی که در روزهای عادی زیر نور نمیآیند. گاهی نتیجهی بررسی یک اختلال، تغییر بزرگی در معماری نیست. شاید فقط یک هشدار تازه باشد، یک روند داخلی بهتر، یک چکلیست کوتاهتر یا یک پیام واضحتر در پنل. اما همان تغییر کوچک ممکن است دفعهی بعد چند دقیقهی مهم را نجات دهد.
بهترین روز آویاتو لزوماً روزی نیست که تعداد زیادی ماشین مجازی ساخته شود یا قابلیت بزرگی منتشر کنیم. گاهی بهترین روز، روزی است که هیچ اتفاق خاصی نمیافتد. سرورها روشن میمانند، شبکه کار میکند، بکاپها ساخته میشوند، کاربران وارد سرویسهایشان میشوند و به کار خودشان ادامه میدهند. کسی لازم نیست دربارهی زیرساخت سؤال کند، چون زیرساخت دقیقاً همان کاری را انجام میدهد که از آن انتظار میرود.
این نامرئی بودن به معنی بیاهمیت بودن نیست. شاید درست برعکس باشد. زیرساخت خوب شبیه پایههای یک ساختمان است؛ کسی برای دیدن آنها به ساختمان نمیآید، اما همهچیز بر آنها ایستاده است. ما آویاتو را نمیسازیم تا کاربران هر روز به آویاتو فکر کنند. آن را میسازیم تا بتوانند کمی کمتر به زیرساخت فکر کنند و کمی بیشتر به محصول، مشتری و کاری که برایشان اهمیت دارد.
شاید بهترین نشانهی موفقیت یک سرویس زیرساختی همین باشد که بیشتر روزها دیده نشود، چون درست کار میکند؛ آرام، پیوسته و بدون اینکه لازم باشد حضور خودش را ثابت کند.