راه طولانی و پرپیچ‌ و خم به سوی تاب‌ آوری - بخش دوم

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

بخش اول:‌ https://vrgl.ir/pugAk

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

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

فناوری: نیاز به به روزرسانی سیستم ها و ابزارها.

فرآیندها: بازنگری در روش های کاری و عملیاتی.

فرهنگ سازمانی: تغییر نگرش ها و رفتارهای کارکنان.

ارتباطات: بهبود شیوه های ارتباطی بین تیم ها و بخش ها.

اما چرا تغییر دشوار است؟

مقاومت در برابر تغییر: انسان ها به طور طبیعی در برابر تغییر مقاومت می کنند.

عدم اطمینان: تغییر می تواند حس عدم اطمینان و نگرانی ایجاد کند.

نیاز به منابع: اجرای تغییرات نیاز به منابعی مانند زمان، پول و انرژی دارد.

نقطه شروع ما برای این سفر دره کامل بودن ویژگی ها می باشد! بسیاری از سازمان ها در این دره قرار دارند. برخی از این ویژگی ها:

تمرکز بر تحویل فیچرها: همانطور که می دانیم سازمان ها بر تحویل سریع تر و بیشتر فیچرهای کسب و کار تمرکز دارند.

جدا بودن تیم های توسعه و عملیات: تیم Dev و Ops به صورت جداگانه عمل می کنند.

اهداف متفاوت: تیم Dev بر اساس تعداد فیچرهای تحویل داده شده ارزیابی می شود، درحالی که تیم Ops بر اساس پایداری و در دسترس بودن سیستم ها.

خب این جدا بودن پیامدهایی مانند عدم همکاری و هماهنگی، انتقال مسئولیت‌ (گردن نگرفتن!) و کاهش کیفیت دارد. برای مثال تمرکز بر سرعت تحویل میتونه باعث کاهش کیفیت بشه(البته این تا حدودی قابل قبول هستش). همچنین در این شرایط در دسترس بودن و پایداری سیستم ها به عنوان مشکل تیم Ops دیده می شود و تیم Dev احساس نمی کنه که مسئولیتی در این مورد داره.

بیایید وضعیت فعلی را با یک چارچوب ساختاریافته ارزیابی کنیم. برای درک بهتر نقاط قوت و ضعف این وضعیت از یک چارچوب ارزیابی استفاده می کنیم:

1- هدف اصلی حداکثر کردن تحویل فیچرهای بیزینس با کمترین هزینه ممکن هستش.

2- داشتن سوالات کلیدی مانند "آیا نیازهای بیزینس به درستی پیاده سازی شده اند؟" یا "چگونه می توانیم فیچرها را سریع تر و با هزینه کمتر تحویل دهیم؟"

3- انجام اقدامات معمول مانند تست های طولانی قبل از لایو کردن برای شناسایی مشکلات احتمالی، اجرای قوانین سختگیرانه برای انتقال به عملیات به دلیل عدم اعتماد به خروجی های تیم Dev، اجرای سیستم ها به صورت پلاگین برای افزایش پایداری و...

این چارچوب ارزیابی معایبی مانند تحویل سریع فیچرها و رضایت بیزینس در کوتاه مدت، معایبی مانند بار اضافی برای تیم Ops، عدم توجه به پایداری و تاب آوری و کاهش کیفیت در بلند مدت دارد.

این رویکرد در محیط‌هایی با سیستم های ساده و منفرد و در شرایط غیر بحرانی ممکن است مناسب باشد. اما در سیستم‌های پیچیده و به هم پیوسته یا در محیط های حساس و بحرانی، باید از این روش اجتناب کنیم. با توجه به تغییرات در دنیای فناوری مانند افزایش پیچیدگی سیستم ها‌ و نیاز به پاسخگویی سریع به تغییرات مارکت، ادامه این رویکرد منطقی نمی باشد. اهمیت تاب آوری بیشتر شده، تهدیدات امنیتی افزایش پیدا کرده اند و خرابی سیستم ها می تواند باعث ایجاد مشکلات جدی شود. در اینجا تاب آوری به سازمان ها کمک می کند تا در برابر اتفاقات غیرمنتظره مقاومت کنند. برای همین نیاز به همکاری بین تیم های Dev و Ops بیش از پیش احساس می شود. رویکرد DevOps به عنوان راهی برای بهبود همکاری و افزایش تاب آوری مطرح شده. سازمان ها متوجه شده اند که باید از روش های فعلی فاصله بگیرند و تیم ها همکاری بیشتری با یکدیگر داشته باشند.

منبع: Uwe Friedrichsen - ufried . com