حالت تاریک
فصل ۱ — زیرساخت بهعنوان کد چیست؟
اگر در تیمی کار میکنید که زیرساخت IT را میسازد و اجرا میکند، فناوری ابری و اتوماسیون زیرساخت باید به شما کمک کند ارزش بیشتری در زمان کمتر و با قابلیت اطمینان بالاتر تحویل دهید. اما در عمل، این فناوریها اندازه، پیچیدگی و تنوع چیزهایی که باید مدیریت شوند را بیوقفه افزایش میدهند.
این فناوریها بهویژه وقتی سازمانها دیجیتال میشوند اهمیت پیدا میکنند. «دیجیتال» همان چیزی است که مردم با لباس رسمی کسبوکار برای بیان این میگویند که سیستمهای نرمافزاری برای کاری که سازمان انجام میدهد ضروریاند.[^1] حرکت به سمت دیجیتال فشار بیشتری بر شما میگذارد تا کار بیشتری انجام دهید و سریعتر انجام دهید. باید سرویسهای بیشتری اضافه و پشتیبانی کنید. فعالیتهای کسبوکار بیشتر. کارکنان بیشتر. مشتریان، تأمینکنندگان و سایر ذینفعان بیشتر.
ابزارهای ابری و اتوماسیون با آسانتر کردن افزودن و تغییر زیرساخت کمک میکنند. اما بسیاری از تیمها برای همگام ماندن با زیرساختی که از قبل دارند به زمان کافی دست نمییابند. آسانتر کردن ساخت چیزهای بیشتر برای مدیریت، کمکی نمیکند. همانطور که یکی از مشتریانم به من گفت: «استفاده از ابر دیوارهایی را که آتش لاستیک ما را محصور نگه میداشت فرو ریخت.»[^2]
بسیاری در برابر تهدید هرجومرج نامحدود، با سختگیرتر کردن فرایندهای مدیریت تغییر واکنش نشان میدهند. امیدوارند با محدود و کنترل کردن تغییرات از هرجومرج جلوگیری کنند. پس ابر را در زنجیر میپیچند.
دو مشکل در این رویکرد وجود دارد. یکی این است که مزایای استفاده از فناوری ابری را از بین میبرد؛ دیگر اینکه کاربران مزایای فناوری ابری را میخواهند. پس کاربران از افرادی که میکوشند هرجومرج را محدود کنند عبور میکنند. در بدترین حالتها، مردم مدیریت ریسک را کاملاً نادیده میگیرند و تصمیم میگیرند در دنیای شجاعانهٔ جدید ابر relevant نیست. آنها IT کابویی[^3] را در آغوش میگیرند که مشکلات متفاوتی اضافه میکند.
فرض این کتاب این است که میتوانید از فناوری ابری و اتوماسیون برای ایجاد تغییرات بهسادگی، ایمن، سریع و مسئولانه بهره ببرید. این مزایا بهصورت آماده از جعبه با ابزارهای اتوماسیون یا پلتفرمهای ابری بیرون نمیآیند. به نحوهٔ استفادهٔ شما از این فناوری بستگی دارند.
DevOps و زیرساخت بهعنوان کد
DevOps جنبشی برای کاهش موانع و اصطکاک بین سیلوهای سازمانی — توسعه، عملیات و سایر ذینفعان درگیر در برنامهریزی، ساخت و اجرای نرمافزار — است. اگرچه فناوری چهرهٔ آشکارتر و از برخی جهات سادهتر DevOps است، فرهنگ، افراد و فرایندها بیشترین تأثیر را بر جریان و اثربخشی دارند. فناوری و شیوههای مهندسی مانند زیرساخت بهعنوان کد باید برای پشتیبانی از تلاشهای پل زدن شکافها و بهبود همکاری به کار روند.
در این فصل توضیح میدهم که زیرساخت مدرن و پویا به ذهنیت «عصر ابری» نیاز دارد. این ذهنیت اساساً با رویکرد سنتی «عصر آهن» که با سیستمهای ایستای پیش از ابر استفاده میکردیم متفاوت است. سه شیوهٔ اصلی برای پیادهسازی زیرساخت بهعنوان کد را تعریف میکنم: همهچیز را بهصورت کد تعریف کنید، همهچیز را در حین کار بهطور مداوم تست و تحویل دهید، و سیستم را از قطعات کوچک و loosely coupled بسازید.
همچنین در این فصل استدلال پشت رویکرد عصر ابری به زیرساخت را توصیف میکنم. این رویکرد دوقطبی کاذب معاملهٔ سرعت بهازای کیفیت را کنار میگذارد. در عوض، از سرعت برای بهبود کیفیت استفاده میکنیم و از کیفیت برای امکان تحویل با سرعت بهره میبریم.
از عصر آهن به عصر ابری
فناوریهای عصر ابری تأمین و تغییر زیرساخت را سریعتر از فناوریهای سنتی عصر آهن میکنند (جدول ۱-۱).
| عصر آهن | عصر ابری |
|---|---|
| سختافزار فیزیکی | منابع مجازیشده |
| تأمین چند هفته طول میکشد | تأمین چند دقیقه طول میکشد |
| فرایندهای دستی | فرایندهای خودکار |
با این حال، این فناوریها لزوماً مدیریت و رشد سیستمهای شما را آسانتر نمیکنند. انتقال سیستمی با بدهی فنی به زیرساخت ابری نامحدود، هرجومرج را شتاب میدهد.
شاید بتوانید از مدلهای حکمرانی سنتی و اثباتشده برای کنترل سرعت و هرجومرجی که فناوریهای جدیدتر آزاد میکنند استفاده کنید. طراحی کامل از پیش، بازبینی دقیق تغییرات و مسئولیتهای بهشدت تفکیکشده نظم را تحمیل میکنند!
متأسفانه این مدلها برای عصر آهن بهینهاند، جایی که تغییرات کند و پرهزینهاند. کار اضافی از پیش اضافه میکنند، با امید به کاهش زمان صرفشده برای تغییرات بعدی. وقتی تغییر دادن بعداً کند و پرهزینه است، این منطقی به نظر میرسد. اما ابر تغییرات را ارزان و سریع میکند. باید از این سرعت برای یادگیری و بهبود مداوم سیستم بهره ببرید. شیوههای کاری عصر آهن مالیات سنگینی بر یادگیری و بهبود هستند.
بهجای استفاده از فرایندهای کند عصر آهن با فناوری تند عصر ابری، ذهنیت جدیدی بپذیرید. از فناوری سریعتر برای کاهش ریسک و بهبود کیفیت بهره ببرید. انجام این کار نیاز به تغییر اساسی رویکرد و شیوههای جدید تفکر دربارهٔ تغییر و ریسک دارد (جدول ۱-۲).
| عصر آهن | عصر ابری |
|---|---|
| هزینهٔ تغییر بالاست | هزینهٔ تغییر پایین است |
| تغییرات نشاندهندهٔ شکستاند (تغییرات باید «مدیریت» و «کنترل» شوند) | تغییرات نشاندهندهٔ یادگیری و بهبودند |
| فرصتهای شکست را کاهش دهید | سرعت بهبود را بیشینه کنید |
| در دستههای بزرگ تحویل دهید، در پایان تست کنید | تغییرات کوچک تحویل دهید، بهطور مداوم تست کنید |
| چرخههای انتشار طولانی | چرخههای انتشار کوتاه |
| معماریهای monolithic (قطعات متحرک کمتر و بزرگتر) | معماریهای microservices (قطعات بیشتر و کوچکتر) |
| پیکربندی GUI-محور یا فیزیکی | پیکربندی بهعنوان کد |
زیرساخت بهعنوان کد رویکرد عصر ابری به مدیریت سیستمهاست که تغییر مداوم را برای قابلیت اطمینان و کیفیت بالا در آغوش میگیرد.
زیرساخت بهعنوان کد
زیرساخت بهعنوان کد رویکردی به اتوماسیون زیرساخت است که بر شیوههای توسعهٔ نرمافزار استوار است. بر روالهای سازگار و قابل تکرار برای تأمین و تغییر سیستمها و پیکربندی آنها تأکید میکند. تغییرات را در کد اعمال میکنید، سپس از اتوماسیون برای تست و اعمال آن تغییرات بر سیستمهایتان استفاده میکنید.
در سراسر این کتاب توضیح میدهم چگونه از شیوههای مهندسی Agile مانند Test Driven Development (TDD)، Continuous Integration (CI) و Continuous Delivery (CD) برای سریع و ایمن کردن تغییر زیرساخت استفاده کنید. همچنین توصیف میکنم چگونه طراحی نرمافزار مدرن میتواند زیرساختی resilient و well-maintained بسازد. این شیوهها و رویکردهای طراحی یکدیگر را تقویت میکنند. زیرساخت well-designed تست و تحویل آسانتری دارد. تست و تحویل خودکار، طراحی سادهتر و تمیزتر را پیش میبرند.
مزایای زیرساخت بهعنوان کد
خلاصه اینکه سازمانهایی که زیرساخت بهعنوان کد را برای مدیریت زیرساخت پویا میپذیرند امیدوارند به مزایایی از جمله موارد زیر دست یابند:
- استفاده از زیرساخت IT بهعنوان enabler برای تحویل سریع ارزش
- کاهش تلاش و ریسک تغییرات زیرساخت
- امکان دسترسی کاربران زیرساخت به منابعی که نیاز دارند، وقتی نیاز دارند
- ارائهٔ ابزار مشترک در توسعه، عملیات و سایر ذینفعان
- ساخت سیستمهای reliable، امن و cost-effective
- visible کردن کنترلهای حکمرانی، امنیت و compliance
- بهبود سرعت عیبیابی و رفع خرابیها
از زیرساخت بهعنوان کد برای بهینهسازی تغییر استفاده کنید
با توجه به اینکه تغییرات بزرگترین ریسک برای سیستم production هستند، تغییر مداوم اجتنابناپذیر است و تغییر دادن تنها راه بهبود سیستم است، منطقی است قابلیت تغییر سریع و reliable را بهینه کنید.[^4] پژوهش Accelerate State of DevOps Report این را تأیید میکند. تغییر مکرر و reliable با موفقیت سازمانی همبستگی دارد.[^5]
وقتی به تیمی توصیه میکنم اتوماسیون را برای بهینهسازی تغییر پیادهسازی کند، چند اعتراض میشنوم. باور دارم اینها از سوءبرداشت دربارهٔ اینکه چگونه میتوانید و باید از اتوماسیون استفاده کنید ناشی میشوند.
اعتراض: «تغییرات را آنقدر مکرر نمیکنیم که خودکارسازی آنها توجیه شود»
میخواهیم فکر کنیم سیستمی میسازیم و بعد «تمام» میشود. در این نگاه، تغییرات زیادی نمیدهیم، پس خودکارسازی تغییرات اتلاف وقت است.
در واقعیت، سیستمهای بسیار کمی از تغییر بازمیایستند — حداقل نه قبل از بازنشستگی. برخی فرض میکنند سطح فعلی تغییر موقتی است. دیگران فرایندهای سنگین change request میسازند تا مردم را از درخواست تغییر دلسرد کنند. این افراد در انکارند. بیشتر تیمهایی که سیستمهای فعالانه استفادهشده را پشتیبانی میکنند، جریان مداومی از تغییرات را مدیریت میکنند.
این نمونههای رایج تغییرات زیرساخت را در نظر بگیرید:
- یک قابلیت ضروری جدید برنامه نیاز دارد پایگاه دادهٔ جدیدی اضافه کنید.
- یک قابلیت جدید برنامه نیاز دارد application server را ارتقا دهید.
- سطح استفاده سریعتر از انتظار رشد میکند. به سرورهای بیشتر، clusterهای جدید و ظرفیت شبکه و storage گسترشیافته نیاز دارید.
- profiling عملکرد نشان میدهد معماری استقرار فعلی برنامه عملکرد را محدود میکند. باید برنامهها را روی application serverهای مختلف دوباره مستقر کنید. این کار تغییراتی در معماری clustering و شبکه میطلبد.
- آسیبپذیری امنیتی تازهاعلامشده در packageهای سیستمعامل شما وجود دارد. باید دهها سرور production را patch کنید.
- باید سرورهایی که نسخهٔ deprecated سیستمعامل و packageهای حیاتی اجرا میکنند بهروزرسانی کنید.
- web serverهای شما خرابیهای متناوب دارند. باید مجموعهای از تغییرات پیکربندی برای تشخیص مشکل انجام دهید. سپس باید یک module را برای رفع مسئله بهروزرسانی کنید.
- تغییر پیکربندیای پیدا میکنید که عملکرد پایگاه داده را بهبود میدهد.
یک حقیقت بنیادین عصر ابری این است: پایداری از تغییر دادن میآید.
سیستمهای patchنشده پایدار نیستند؛ آسیبپذیرند. اگر نتوانید مشکلات را بهمحض کشف فوری رفع کنید، سیستم شما پایدار نیست. اگر نتوانید سریع از خرابی بازیابی کنید، سیستم شما پایدار نیست. اگر تغییراتی که میدهید downtime قابل توجهی داشته باشد، سیستم شما پایدار نیست. اگر تغییرات مکرراً شکست بخورند، سیستم شما پایدار نیست.
اعتراض: «باید اول بسازیم و بعد خودکارسازی کنیم»
شروع با زیرساخت بهعنوان کد منحنی تندی دارد. راهاندازی ابزارها، سرویسها و شیوههای کاری برای خودکارسازی تحویل زیرساخت کار زیادی است، بهویژه اگر پلتفرم زیرساخت جدیدی هم میپذیرید. ارزش این کار قبل از شروع ساخت و استقرار سرویسها با آن سخت است نشان داد. حتی بعد از آن هم ممکن است برای کسانی که مستقیماً با زیرساخت کار نمیکنند ارزش آشکار نباشد.
ذینفعان اغلب تیمهای زیرساخت را تحت فشار میگذارند تا سیستمهای جدید cloud-hosted را سریع، دستی بسازند و بعداً نگران خودکارسازی باشند.
سه دلیل وجود دارد که خودکارسازی بعداً ایدهٔ بدی است:
- خودکارسازی باید تحویل سریعتر را ممکن کند، حتی برای چیزهای جدید. پیادهسازی خودکارسازی بعد از انجام بیشتر کار، بسیاری از مزایا را از دست میدهد.
- خودکارسازی نوشتن تستهای خودکار برای آنچه میسازید را آسانتر میکند. و وقتی مشکل پیدا میکنید، رفع و rebuild سریع را آسانتر میکند. انجام این کار بهعنوان بخشی از فرایند ساخت به ساخت زیرساخت بهتر کمک میکند.
- خودکارسازی یک سیستم موجود بسیار سخت است. خودکارسازی بخشی از طراحی و پیادهسازی سیستم است. برای افزودن خودکارسازی به سیستمی که بدون آن ساخته شده، باید طراحی و پیادهسازی آن سیستم را بهشکل قابل توجهی تغییر دهید. این برای تست و استقرار خودکار هم صادق است.
زیرساخت ابری که بدون خودکارسازی ساخته شود زودتر از انتظار شما write-off میشود. هزینهٔ نگهداری و تعمیر دستی سیستم میتواند بهسرعت بالا برود. اگر سرویسی که اجرا میکند موفق باشد، ذینفعان شما را تحت فشار میگذارند تا گسترش دهید و قابلیت اضافه کنید، نه اینکه برای rebuild متوقف شوید.
همین دربارهٔ ساخت سیستم بهعنوان آزمایش هم صادق است. وقتی proof of concept بالا و در حال اجراست، فشار برای رفتن به چیز بعدی وجود دارد، نه برگشت و ساخت درست. و در واقع، خودکارسازی باید بخشی از آزمایش باشد. اگر قصد دارید از خودکارسازی برای مدیریت زیرساخت استفاده کنید، باید بفهمید این چگونه کار میکند، پس باید بخشی از proof of concept شما باشد.
راهحل این است که سیستم را بهصورت افزایشی بسازید و در حین کار خودکارسازی کنید. مطمئن شوید جریان پایداری از ارزش تحویل میدهید، در حالی که قابلیت انجام مداوم آن را هم میسازید.
اعتراض: «باید بین سرعت و کیفیت یکی را انتخاب کنیم»
طبیعی است فکر کنید فقط با کمگذاشتن در کیفیت میتوانید سریع حرکت کنید، و فقط با حرکت آهسته میتوانید کیفیت بگیرید. شاید این را بهصورت یک پیوستار ببینید، همانطور که در شکل ۱-۱ نشان داده شده.
شکل ۱-۱. ایدهٔ اینکه سرعت و کیفیت دو سر یک طیفاند، دوقطبی کاذب است.
با این حال، پژوهش Accelerate که پیشتر اشاره کردم (بخش «از زیرساخت بهعنوان کد برای بهینهسازی تغییر استفاده کنید») خلاف این را نشان میدهد:
این نتایج نشان میدهند معاملهای بین بهبود عملکرد و دستیابی به سطوح بالاتر پایداری و کیفیت وجود ندارد. بلکه high performerها در همهٔ این معیارها بهتر عمل میکنند. این دقیقاً همان چیزی است که جنبشهای Agile و Lean پیشبینی میکنند، اما بسیاری از dogmaهای صنعت ما هنوز بر فرض کاذب استوارند که سریعتر رفتن یعنی معامله با سایر اهداف عملکردی، نه اینکه آنها را ممکن و تقویت کند.
— Nicole Forsgren, PhD, Accelerate
بهاختصار، سازمانها نمیتوانند بین خوب بودن در تغییر یا خوب بودن در پایداری انتخاب کنند. معمولاً یا در هر دو خوباند یا در هر دو بد.
ترجیح میدهم کیفیت و سرعت را بهجای پیوستار، بهصورت quadrant ببینم،[^6] همانطور که در شکل ۱-۲ نشان داده شده.
شکل ۱-۲. سرعت و کیفیت به quadrantها نگاشت میشوند.
این مدل quadrant نشان میدهد چرا تلاش برای انتخاب بین سرعت و کیفیت به mediocrity در هر دو منجر میشود:
quadrant پایین-راست: اولویت سرعت بر کیفیت
این فلسفهٔ «move fast and break things» است. تیمهایی که برای سرعت بهینه میکنند و کیفیت را قربانی میکنند، سیستمهای messy و fragile میسازند. به quadrant پایین-چپ سر میخورند چون سیستمهای sloppy آنها را کند میکند. بسیاری از startupهایی که مدتی اینطور کار کردهاند از از دست دادن «mojo» خود شکایت میکنند. تغییرات سادهای که در گذشته سریع انجام میدادند اکنون روزها یا هفتهها طول میکشد چون سیستم tangle شده.
quadrant بالا-چپ: اولویت کیفیت بر سرعت
همچنین شناختهشده بهعنوان «کارهای جدی و مهم انجام میدهیم، پس باید درست انجام دهیم.» سپس فشار deadlineها «workaround»ها را پیش میبرد. فرایندهای heavyweight موانعی برای بهبود میسازند، پس بدهی فنی همراه با فهرست «مشکلات شناختهشده» رشد میکند. این تیمها به quadrant پایین-چپ سر میخورند. با سیستمهای low-quality تمام میکنند چون بهبود آنها خیلی سخت است. در پاسخ به شکستها فرایند بیشتری اضافه میکنند. این فرایندها بهبود را سختتر و fragility و ریسک را بیشتر میکند. این به شکستهای بیشتر و فرایند بیشتر منجر میشود. بسیاری از کسانی که در سازمانهایی با این شیوه کار میکنند فرض میکنند این عادی است،[^7] بهویژه کسانی که در صنایع risk-sensitive کار میکنند.[^8]
quadrant بالا-راست هدف رویکردهای مدرن مانند Lean، Agile و DevOps است. توانایی حرکت سریع و حفظ سطح بالای کیفیت ممکن است فانتزی به نظر برسد. با این حال، پژوهش Accelerate ثابت میکند بسیاری از تیمها به این دست مییابند. پس در این quadrant «high performer»ها را پیدا میکنید.
چهار معیار کلیدی
تیم پژوهش Accelerate در DORA چهار معیار کلیدی برای تحویل نرمافزار و عملکرد عملیاتی شناسایی میکند.[^9] این پژوهش معیارهای مختلف را survey میکند و یافته که این چهار تا قویترین همبستگی با میزان موفقیت سازمان در دستیابی به اهدافشان دارند:
Delivery lead time
زمان سپریشده برای پیادهسازی، تست و تحویل تغییرات به سیستم production
Deployment frequency
چند وقت یکبار تغییرات را به سیستمهای production deploy میکنید
Change fail percentage
چند درصد تغییرات یا سرویس impaired ایجاد میکنند یا نیاز به اصلاح فوری دارند، مانند rollback یا fix اضطراری
Mean Time to Restore (MTTR)
چقدر طول میکشد وقتی outage یا impairment برنامهریزینشده رخ میدهد، سرویس را بازیابی کنید
سازمانهایی که در برابر اهدافشان — چه revenue، share price یا معیارهای دیگر — عملکرد خوبی دارند، در این چهار معیار هم عملکرد خوبی دارند و بالعکس.
ایدههای این کتاب هدفشان کمک به تیم و سازمان شما برای عملکرد خوب در این معیارهاست. سه شیوهٔ اصلی برای زیرساخت بهعنوان کد میتواند به دستیابی به این کمک کند.
سه شیوهٔ اصلی برای زیرساخت بهعنوان کد
مفهوم عصر ابری از ماهیت پویای زیرساخت و پلتفرمهای برنامه مدرن برای تغییر مکرر و reliable بهره میبرد. زیرساخت بهعنوان کد رویکردی به ساخت زیرساخت است که تغییر مداوم را برای reliability و کیفیت بالا در آغوش میگیرد. پس تیم شما چگونه میتواند این کار را انجام دهد؟
سه شیوهٔ اصلی برای پیادهسازی زیرساخت بهعنوان کد وجود دارد:
- همهچیز را بهصورت کد تعریف کنید
- همهٔ کار در جریان را بهطور مداوم تست و تحویل دهید
- قطعات کوچک و ساده بسازید که بتوانید مستقل تغییرشان دهید
اکنون هر کدام را خلاصه میکنم تا زمینهٔ بحثهای بعدی فراهم شود. بعداً فصلی را به اصول پیادهسازی هر یک از این شیوهها اختصاص میدهم.
شیوهٔ اصلی: همهچیز را بهصورت کد تعریف کنید
تعریف همهٔ چیزهایتان «بهصورت کد» شیوهٔ اصلی برای تغییر سریع و reliable است. چند دلیل دارد که این کمک میکند:
Reusability
اگر چیزی را بهصورت کد تعریف کنید، میتوانید نمونههای زیادی از آن بسازید. میتوانید چیزهایتان را سریع repair و rebuild کنید، و دیگران میتوانند نمونههای یکسان از آن چیز بسازند.
Consistency
چیزهایی که از کد ساخته میشوند هر بار به یک شکل ساخته میشوند. این رفتار سیستم را predictable میکند، تست را reliableتر میکند و تست و تحویل مداوم را ممکن میسازد.
Transparency
همه میتوانند با نگاه به کد ببینند چیز چگونه ساخته شده. مردم میتوانند کد را review کنند و بهبود پیشنهاد دهند. میتوانند چیزهایی برای استفاده در کدهای دیگر یاد بگیرند، بینش برای عیبیابی به دست آورند و برای compliance review و audit کنند.
مفاهیم و اصول پیادهسازی تعریف چیزها بهصورت کد را در فصل ۴ گسترش میدهم.
شیوهٔ اصلی: همهٔ کار در جریان را بهطور مداوم تست و تحویل دهید
تیمهای زیرساخت مؤثر در تست سختگیرند. از اتوماسیون برای deploy و تست هر component سیستم و یکپارچهسازی همهٔ کاری که همه در جریان دارند استفاده میکنند. در حین کار تست میکنند، نه اینکه منتظر تمام شدن کار بمانند.
ایده این است که کیفیت را درون ساخت بسازید، نه اینکه بعداً سعی کنید کیفیت را تست کنید.
بخشی از این که مردم اغلب نادیده میگیرند این است که شامل یکپارچهسازی و تست همهٔ کار در جریان میشود. در بسیاری از تیمها، مردم روی کد در branchهای جدا کار میکنند و فقط وقتی تمام میکنند یکپارچه میکنند. با این حال، طبق پژوهش Accelerate، تیمها وقتی همه حداقل روزانه کارشان را یکپارچه میکنند نتایج بهتری میگیرند. CI شامل merge و تست کد همه در طول توسعه است. CD این را فراتر میبرد و کد mergeشده را همیشه production-ready نگه میدارد.
جزئیات بیشتر دربارهٔ تست و تحویل مداوم کد زیرساخت را در فصل ۸ توضیح میدهم.
شیوهٔ اصلی: قطعات کوچک و ساده بسازید که بتوانید مستقل تغییرشان دهید
تیمها وقتی سیستمهایشان بزرگ و tightly coupled است در تنگنا میافتند. هرچه سیستم بزرگتر باشد، تغییر سختتر و شکستن آسانتر است.
وقتی codebase یک تیم high-performing را ببینید، تفاوت را میبینید. سیستم از قطعات کوچک و ساده تشکیل شده. هر قطعه آسان فهم است و interfaceهای clearly defined دارد. تیم میتواند هر component را بهتنهایی بهراحتی تغییر دهد و هر component را بهصورت isolated deploy و test کند.
اصول پیادهسازی این شیوهٔ اصلی را در فصل ۱۵ عمیقتر بررسی میکنم.
جمعبندی
برای گرفتن ارزش ابر و اتوماسیون زیرساخت، به ذهنیت عصر ابری نیاز دارید. این یعنی از سرعت برای بهبود کیفیت بهره ببرید و کیفیت را درون بسازید تا سرعت به دست آید. خودکارسازی زیرساخت کار میطلبد، بهویژه وقتی در حال یادگیری هستید. اما انجام آن به شما کمک میکند تغییرات بدهید، از جمله ساخت خود سیستم در نخستین مرحله.
بخشهای یک سیستم زیرساخت معمول را توصیف کردم، چون اینها پایهٔ فصلهایی هستند که نحوهٔ پیادهسازی زیرساخت بهعنوان کد را توضیح میدهند.
در پایان، سه شیوهٔ اصلی برای زیرساخت بهعنوان کد را تعریف کردم: تعریف همهچیز بهصورت کد، تست و تحویل مداوم، و ساخت قطعات کوچک.
[^1]: برخلاف آنچه بسیاری از همان مردم چند سال پیش میگفتند: نرمافزار «بخشی از کسبوکار اصلی ما نیست.» پس از پیروی از این توصیه و برونسپاری IT، سازمانها فهمیدند توسط کسانی که نرمافزار بهتر را راه رقابت میبینند نه هزینهای برای کاهش، از آنها پیشی گرفته میشوند.
[^2]: طبق ویکیپدیا، آتش لاستیک دو شکل دارد: «رویدادهای سوختن سریع که تقریباً بلافاصله به از دست دادن کنترل منجر میشوند، و pyrolysis سوختن آهسته که میتواند بیش از یک دهه ادامه یابد.»
[^3]: منظورم از «IT کابویی» ساخت سیستمهای IT بدون روش مشخص یا توجه به پیامدهای آینده است. اغلب کسانی که هرگز سیستمهای production را پشتیبانی نکردهاند سریعترین مسیر برای کارکردن را بدون در نظر گرفتن امنیت، نگهداری، عملکرد و سایر نگرانیهای operability انتخاب میکنند.
[^4]: طبق Gene Kim، George Spafford و Kevin Behr در The Visible Ops Handbook (IT Process Institute)، تغییرات ۸۰٪ outageهای برنامهریزینشده را ایجاد میکنند.
[^5]: گزارشهای پژوهش Accelerate در State of DevOps Report سالانه و در کتاب Accelerate اثر Dr. Nicole Forsgren، Jez Humble و Gene Kim (IT Revolution Press) در دسترس است.
[^6]: بله، در یک consultancy کار میکنم، چرا میپرسید؟
[^7]: این نمونهای از «Normalization of Deviance» است؛ یعنی مردم به کار کردن به شیوههایی که ریسک را افزایش میدهند عادت میکنند. Diane Vaughan این اصطلاح را در The Challenger Launch Decision (University Of Chicago Press) تعریف کرد.
[^8]: طعنهآمیز (و ترسناک) است که اینقدر مردم در صنایعی مانند finance، government و health care سیستمهای IT fragile — و فرایندهایی که بهبود آنها را مسدود میکنند — را عادی و حتی مطلوب میدانند.
[^9]: DORA، اکنون بخشی از Google، تیم پشت Accelerate State of DevOps Report است.