آنکالبودن چطور من رو به مهندسی که هستم تبدیل کرد
خلاصهٔ کاملتر
نویسنده میگه با اینکه هیچوقت رسماً عنوان DevOps یا SRE نداشته، بیشتر ساعتهای مهندسیِ سالهای اول کارش صرف فهمیدن و مهارِ حادثهها (incident) شده. بدون اغراق، آنکالبودن همون چیزیه که او رو به مهندسی که الان هست تبدیل کرده.
او ۷.۵ سال (۲۰۱۰ تا ۲۰۱۷)، از جمله حدود ۱۵ ماهی که مدیر تیم بوده، آنکالِ کشِ توزیعشدهی توییتر بوده؛ حتی یه روز بعد از تاریخ تولد فرزند اولش. این هر سرویسی نبود: کش بالاترین throughput (بر اساس درخواست در ثانیه) رو بین سرویسهای توییتر داشت و چون یه سرویسِ بار-برِ حیاتی بود، اصلاً بیمشکل نبود؛ توی نظرسنجی حادثههای کش که با Dan Luu نوشتن، دستکم دوازده حادثهی پرسروصدا (tier 0 یا tier 1، یعنی افت گستردهی کل سایت) شمردن که کاملاً یا عمدتاً به کش نسبت داده میشد.
و او عاشق این کار بوده؛ هیجان، وزنِ واقعیتی که روی فهم و تواناییات فشار میاره، و لحظههایی که به مغزِ ADHDش اجازهی تمرکز میداد. مثل یه آتشنشانِ خوب، معمولاً به سمت آتش میدوید.
آنکالبودن مهمترین درسهای فنی و رفتاریاش رو بهش داد: یاد گرفت قابلپیشبینیبودن اغلب از سریعبودن مهمتره و تأخیرِ دُم (tail latency) توی یه سیستمِ مقیاسدار خیلی مهمتر از میانه یا میانگینه. یاد گرفت معماری ساده و شفاف توی لحظهی بحران چقدر ارزش داره، تعادلهایی که کتابها دربارهی الگوهای رایج طراحی نمیگن، و اینکه تعالیِ عملیاتی (observability کامل، پیکربندی یکدست، آمادهبودن برای اتوماسیون، مقادیر پیشفرض منطقی) از تصمیمهای طراحیِ خوب درمیاد نه وصلهکاریِ دو هفته مونده به لانچ. اما به گفتهی او شاید مهمتر، چیزی بود که دربارهی کار با آدمها یاد گرفت.
نکات کلیدی:
- آنکالبودن، بیشتر از هر تجربهی دیگهای یه مهندس زیرساخت رو شکل میده
- ۷.۵ سال آنکالِ کشِ توییتر، با دهها حادثهی بزرگِ سراسری
- قابلپیشبینیبودن از سریعبودن مهمتره و تأخیرِ دُم از میانگین
- تعالیِ عملیاتی از طراحی خوب درمیاد، نه وصلهکاریِ آخرِ کار
