خانه / Agile / از آقا یا خانم DevOps توقع بیجا نداشته باشیم!!!

از آقا یا خانم DevOps توقع بیجا نداشته باشیم!!!

از آقا یا خانم DevOps توقع بیجا نداشته باشیم!!!

احتمالا شما هم با دیدن عبارت “آقا یا خانم DevOps” لبخند یا شاید تلخند زدید. بله حق دارید؛ اما واقعیت تلخی است که در حال اپیدمی شدن می باشد. قبلا در پستی که می توانید اینجا مشاهده بفرمائید؛ مقدماتی در مورد DevOps بیان کردم؛ و اشاره کردم که برخی برداشتی خواهند داشت که زنبیل یا سبدی برداشته و به مغازه یا فروشگاهی رفته و چند تا DevOps سفارش دهند؛ و سپس خاطر جمع و راحت از اینکه از چند روز آینده به ریلیزهای مداوم و زیاد و مطمئن دست خواهند یافت. واقعیت تلخ در اینجا هم به این صورت می باشد که این مورد نیز اتفاقی است که خیلی جاها در حال افتادن می باشد. به شخصه عبارت :”قصد داریم و می خواهیم که DevOps را خریداری کنیم؛ یا منتظریم سازمان DevOps را بخرد” را شنیده ام. خوب داستان تلخ اینچنینی محدود به DevOps به تنهایی نمی شود. در مورد اجایل و مشتقات آنها (که اکثر اوقات هم محدود به اسکرام می شود) نیز این داستان غم انگیز بشدت وجود داشته. در مورد مایکروسرویس نیز با سرعت بسیار زیادی در حال تبدیل شدن این سبک تفکر و معماری به برداشت های سطحی و مجهول و همه گیر شدن در جامعه می شود. DevOps البته با توجه به ماهیت Cultural ای که دارد بیشتر از بقیه موارد مستعد افتادن در این دام می باشد.

قبلا در پستی با عنوان مایکروسرویس؛ ادامه دهنده چرخه ی تسلسل اجایل به فرهنگ و جایگاه DevOps در سازمان و پیش نیازهای آن مختصرا پرداختم. در آنجا به صراحت به خود اجایل و اجایلیتی و فرهنگ ورای آن؛ نقش و جایگاه Continues Integration و Continues Deployment اشاره شده و هدف و جایگاه DevOps را نیز مورد اشاره قرار دادم.

نظر به درک و برداشت های غلط و اشتباهی که در مورد مفاهیم DevOps؛ CD؛ مایکروسرویس و … وجود دارد در این مقاله کوتاه سعی در اشاره به نکاتی بر اساس تجربیات شخصی خود؛ در این زمینه خواهم داشت.

  1. هدف و بیان مساله را به دقت و با تمرکز و وسواس بیشتری تعیین کنیم

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

  • هدف تعیین شده: راه اندازی CD جهت ریلیزهای اتومات و سریع(متاسفانه غالبا از واژه DevOps در این مواقع استفاده می شود).
  • بیان مسئله موجود: تعداد باگ های رفع شده و فیچرهای توسعه داده شده ی کمتر از میزان تعهد شده در هر iteration.

از شرایط خاص جهت آوردن دلیل و ایجاد یکسری شرایط جهت همگن خواندن بیان مسئله و هدف بالا که بگذریم؛ این هارمونی نامناسب گاهی بدلیل تعیین هدف بدون توجه و تشریح مسئله می باشد؛ و گاهی بدلیل بی اطلاعی و عدم اطلاع کافی هم در زمینه اطلاعات کافی از مسئله موجود در سازمان می باشد و هم می تواند ناشی از دانش و تجربه ی ناکافی و مایندست نا مناسبت نسبت به مقوله مهندسی نرم افزار و توسعه سیستم های نرم افزاری ناشی شود. بی شک هر سیستم نرم افزاری توسعه داده شده از دل و ماهیت یک بیزینس و کانتکست خاص بیرون آمده و اکثر اوقات بهترین راه حل برای مسئله x نمی تواند راه حل مناسبی برای مسئله و دامنه y باشد؛ حتی اگر اولین راه حل خطور کرده به ذهن باشد.

  1. مسیر مستقیم از Problem به Solution را طی کنیم

این مورد نیز یکی از مسایل مبتلا به می باشد. گاهی ناخواسته دچار این دام بی صدا خواهیم داشت. که هر چند در حال حل مسئله می باشیم. اما مسیر را بصورت عکس راهپیمایی می کنیم. یعنی با یک تعریف اولیه و abstract از problem و انتخاب یک solution سعی می کنیم که آن Solution را باز کرده و تشریح کنیم و جوانب آن را بسنجیم و سپس problem خود را بر solution انتخاب شده بسط و گسترش داده و تلفیق کنیم. بیشترین تمرکز باید معطوف به روشن شدن و بیان واضع دامنه مسئله باشد و سپس بر اساس آن به ارائه راه حل های موجود اقدام کنیم. عدم توجه به این موضوع یعنی حرکت از مسئله به راه حل می تواند منجر به راه حل(هایی) شود که هرچند ممکن هم هست که در شرایط فعلی گزینه مناسبی باشند اما می تواند سیستم را برای پاسخگویی به نیازهایی آتی با مشکل مواجه کند. به زبانی دیگر منجر به این خواهد شد که براحتی چابکی را با یک راه حل بهترین در حال حاضر از سیستم بگیریم. بدون شک تشریح و بیان مناسب از مسئله می تواند حاوی اطلاعات ارزشمندی باشد که در یافتن راه حل مناسب بسیار کمک کننده باشد.

  1. به استانداردهای موجود احترام بگذاریم

این شرایط و راه حل استاندارد برای مسئله ما نمی باشد؛ بلکه سیستم هایی آنها است که از ابتدا به ساکن درست بنا نهاده شده است؛ و ما از این مورد بنا بر شرایط خود استفاده می کنیم. جمله و عبارت طولانی که احتمالا بارها و بارها شنیده و یا حتی به زبان آورده ایم. شاید فی نفسه عباراتی از این دست غلط یا اشتباه نباشند اما همین عبارت می توانند تبدیل بشوند به همان جو و شرایط نامناسب بی صدا که منجر بشوند به انتخاب هدف و ایجاد راه حل های نامناسب. توجه داشته باشیم که اکثر مسائلی که با آنها مواجه هستیم راه حل هایی برای آنها وجود داشته و می توان با جستجوی مناسب و دقیق به راه حل مناسب دست پیدا کرد. در صورتی که ابزاری یا فریمورکی کاملا با مسئله ما متناسب نمی باشد همیشه تغییر در آن ابزار بهترین گزینه نمی باشد. استاندارد همیشه در یک کانتکست خاص معرفی و بیان می شود و بر اساس آن اقدام به ارئه solution هایی خواهیم نمود. در صورتی که استاندارد(حتی استاندارد های شخصی ساز) با استاندارد های بیان شده در داکیومنت یک ابزار یا وسیله ی همخوانی ندارد؛ شاید انتخاب و راه حل دیگر گزینه مناسب تری باشد. اقدام به استفاده شخصی شده و عدم توجه به شرایط استفاده و موارد استفاده بیان شده برای هر ابزار آنهم در شرایط عدم دانش کافی و مناسب نیز می تواند در کوتاه/طولانی مدت باز ما را ببرد به “آن نمی دانم کجای زیبا“. باز هم تاکید می کنم: هر استاندارد در یک کانتکست خاص معنی پیدا می کند.

  1. به پیش نیازهای موجود برای هر انتخاب توجه و دقت کافی داشته باشیم

طبیعتا هر انتخاب و راه حلی در شرایطی و با وجود داشتن یکسری شرایط و پیش نیازها می تواند بازده و عایدی مناسب داشته باشد؛ و هر چه از این شرایط مورد نیاز بدور باشیم میزان منفعت مورد نظر کمتر و کمتر خواهد شد و به سختی بدست خواهد آمد. و حتی گاها نتیجه ی کاملا عکس در پی خواهد داشت. به عنوان مثال می توان به مایکروسرویس اشاره کرد. مارتین فاولر اشاره می کند که برای رفتن سمت این سبک تفکر و معماری نیاز می باشد که شما باید به اندازه کافی قد بلند داشته باشید ! هر چند ممکن است در نگاه اول منفعت های جاه طلبانه ی مایکروسرویس ما را در انتخاب مصمم تر کند اما باید به جایگاه این سبک معماری در چرخه تسلسل اجایل آگاه باشیم و آگاهانه دست به انتخاب بزنیم. بی شک بدون وجود یک سری پیش نیازها نمی توان انتظار هیچگونه معجزه ای داشت. این مورد همچنین در مورد مواردی از جمله CD ها و داکریسم و بخصوص DevOps که عنوان اصلی این مقاله را نیز به خود اختصاص داده صادق می باشد. emerge design یکی از استدلال هایی است که در نبود برخی پیش نیازها و رفتن به سمت یک راه حل یا ابزار بکار برده می شود. در این زمینه محتاط باشید به اندازه کافی!!!

  1. Ubiquitous Language را در مورد دامنه مسئله و راه حل ها و ابزارهای ممکن بصورت صحیح استفاده نمائید

یکی از بدترین موارد تعریف نامناسب و غیر صحیح و درک نامناسب از مواردی است که قصد استفاده از آن در دامنه ی مسئله را خواهیم داشت. فرض کنید قصد استفاده از یک ابزار متدولوژی تفکر معماری فریمورک و … را داریم. اما تعریف و درک درست و صحیحی از آن در افراد درگیر با مسئله نداریم. زبان مشترک و صحیح باعث می شود:

  • اولا فلسفه و ماهیت صحیح راه حل مورد نظر بین همه ی افراد درگیر روشن شود.
  • و دوم و مهمتر اینکه از برداشت های نا صحیح و جابجا به عنوان برخی اصطلاحات و ابزارها که می تواند تاثیرات نامناسبی به دنبال داشته باشد جلوگیری شود.
  • تاثیر بعدی از لیبل زدن غیر صحیح و ایجاد پست های با عناوین غلط مثل DevOps جلوگیری خواهد شد. اگر ما برای راه اندازی یک خط تست و بیلد اتومات با کمک هر ابزاری از افراد فنی خارج از تیم تولید کمک گرفتید لزوما به این معنی نیست که به تفکر و فرهنگ ورای DevOps دست پیدا کردیم. البته حتما گام هایی به این سمت برداشته ایم.

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

  1. Problem Space باید مرکز توجه قرار بگیرد؛ تمام Solution ها از دامنه ی مسئله باید مشتق شود

به هنگام تفکر و بررسی راه حل ها؛ در مرکز توجه قرار دادن فضای مسئله بسیار حیاتی می باشد. تمامی راه حل ها و فضاهای راه حل ها باید مشتق شده از فضای مسئله و در راستای حل مسائل موجود در این فضا باشد. این امر به ما کمک می کند که از راه حل های غیر ضروری چه از نظر راه حل هایی که فضای مسئله را کاملا پوشش نمی دهد و چه راه حل هایی که بیش از حد مورد نیاز می باشد جلوگیری می شود. توجه به YAGNI می تواند بسیار کمک کنده باشد.

  1. راه حل های برخی مسائل گاها از آن چیزی که فکر می کنیم متفاوت خواهد بود

هر چند تاکید بر دامنه ی مسئله و بیان مساله را در بالا ذکر کردم. ولی باید توجه داشت که راه حل گاهی از جای دیگری که فکرش را نمی کنیم نشات می گیرد. به عنوان مثال فرض کنیم می خواهیم به ریلیز سریعتر دست پیدا کنیم. راه حل این مسئله همیشه خط تولید تست و ریلیز اتومات نیست؛ معمولترین راه حلی که ممکن است در نگاه اول انتخاب شود. گاهی اوقات یک فرآیند مانوال ولی با فرآیند تولید و توسعه صحیح تر و refactor نمودن در ساختار کد بیس نیز می تواند ما را در رسیدن به این هدف کمک کند. در واقع هرچند هدف ما بر ریلیز و بصورت ضمنی بر خط تولید اشاره دارد ولی ما می توانیم بدون تغییر در این خط تولید نیز به این هدف برسیم و اتفاقا پس از همین refactor ها در فرآیند تولید و کد بیس هست که CI یا CD ها بیشتر مثمر ثمر خواهند بود.

  1. به همان اندازه که به خروجی های راه حل ها توجه داریم بر ورودی های آن نیز متمرکز باشیم

این یک مورد بسیار کلیدی و حساس در انتخاب بسیاری از راه حل می باشد. فرض کنید ما یک CD مناسب راه اندازی کردیم؛ ولی از CI غافل شدیم. خوب این CD یک خط تولید اتوماتیک برای ما مهیا می کند که بر اساس ورودی اقدام به ایجاد خروجی که ریلیزهای اتومات به همراه منافع آن می باشد؛ می کند. در صورتی که از CI غافل بشویم و برای آن ارزشی قایل نشویم خوب ما اکثرا با یک خط بیلد و ریلیز خوب سروکار داریم که اکثر مواقع بیکار هست و ورودی برا اقدام ندارد. این چرخه ی عقب گرد طبیعتا می تواند ادامه داشته باشد و ما را راهنمایی کند که پله های مناسب رو به ترتیب مناسب طی کنیم.

  1. فراموش نکنیم؛ همه چیز از دستان و سیستم توسعه دهنده آغاز می شود.

به هر چرخه و موردی که نگاه کنیم؛ از چرخه های اجایل تا DevOps تا داکریسم و CD و … تمامی اکوسیستم ها پیش درآمد شان تک تک توسعه دهنده ها هستند. پس وقتی که خانه ای داریم که از پای بست بسی ویران است امید معجزتی نداشته باشیم. تغییر مایندست و ذهنیت توسعه دهنده ها؛ اصلاح فرآیند ها؛ اعمال برخی refactor ها؛ محترم شمردن و اهمیت دادن به کالچرهایی از جمله TDD ایجاد یک ساختار و معماری مناسب برای سیستم می تواند ریشه ی بسیاری از مشکلات باشد و همچنین زمینه و پیش نیاز مناسبی برای مراحل بعدی داشته باشد. وقتی ما بدلیل معماری نامناسب و عدم وجود تست های مناسب برای هر رفع باگ و توسعه فیچر به ناچار زمان زیادی را مجبور هستیم صرف کنیم از CI و CD نمی توان انتظار بیش از حد داشت. تا زمانی که API مناسبی متناسب با دامنه مسئله نتوانیم توسعه دهیم سایر راه حل کمکی نمی توانند بکنند. توجه به این نکته هم می تواند بسیار مهم و حیاتی باشد که Refactor همیشه به معنی انجام دادن و تغییر دادن برخی ساختار های فعلی نمی باشد. بسیار اوقات Refactor به معنی انجام ندادن برخی کارهای اشتباه فعلی است- رعایت و توجه به قانون قانون چاله. تاکید مجدد می کنم همه چیز از سیستم توسعه دهنده ها آغاز می شود. قدم اول اگر خوب برداشته نشود بی شک این دیوار تا ثریا کج خواهد رفت؛ ولو اینکه به working software هم برسیم. اگر با یکسری سیستم های در حال کار autonomous سرو کار داریم و قصد داریم که این سیستم ها با هم communicate داشته باشند؛ قدم اول داشتن زیر ساخت مناسب می باشد. مشکلات کوچکتری که در هر کدام از این سیستم ها در حال حاظر وجود دارد؛ مثل DI نا مناسب هر چند ممکن است در حال حاظر چندان اهمیت نداشته باشند؛ ولی با بزرگتر شدن سیستم ها و با تجمیع این مشکلات؛ بدون شک به یک BBoM غیر قابل نگهداری ختم خواهند شد. نکته ی مهمتر دیگر اینکه از سر نوشتن هر سیستمی با مایندست قبلی باعث ایجاد همین سیستم فعلی در آینده خواهد شد؛ چرا که این مایندست اشتباه و غیر مناسب بود که سیستم را به این سمت و حال و روز کشانده بود و نه ابزارها یا موارد دیگر. پس تغییر مایندست اشتباه را در اولویت اول قرار دهیم. توجه به توانایی نیروهای توسعه دهنده نیز بسی مهم هست؛ چرا که هر تصمیمی در نهایت باید توسط افراد تیم پیاده سازی شود؛ یک تیم بد و نا مناسب همیشه یک تصمیم خوب را نیز ممکن است اشتباه پیاده سازی کنند.

  1. داستان های موفقیت دیگران می تواند بسیار کمک کننده باشد؛ اما در نهایت این ما هستیم که بر اساس Problem Space خود باید تصمیم بگیریم

یکی از تفاوت هایی که کانسپتی مثل مایکروسرویس با SOA دارد همین هست که مایکروسرویس از دل پیاده سازی های واقعی و عملی در شرکت هایی از جمله Netflix بیرون آمده است. داستان ها و البته گاهی سرگردانی هایی زیادی در کامیونیتی درمورد آن وجود دارد. وجود این داستان های موفقیت آمیز و case study ها می تواند بسیار کمک کننده باشد. تجربه ی اتفاق افتاده؛ راهنمایی های انجام شده؛ توصیه های ارئه شده همگی می تواند بسیار کمک کننده باشند؛ ولی به هیچ وجه توصیه به تقلید و کپی برداری محض به صرف اینکه ممکن است فضای مسئله ی ما مشابه داستان آن ها باشد نمی شود. فاکتورهای بسیار مهم دیگری می تواند بر solutionهای اینچنین تاثیر گذار باشند. وجود زیر ساخت مناسب؛ کالچرهای مورد نظر؛ پیش نیازهای مورد نیاز؛ پرکتیشنرهای مورد نیاز حمایت های سازمانی لازم و … برخی مواردی هستند که معمولا در این use case ها در نظر گرفته نمی شوند. کوتاه سخن اینکه به ندرت پیش می آید که Problem Space دو مسئله کاملا شبیه و منطبق با هم باشند. اگر فضای مسئله ما شبیه به فضای use case مورد نظر؛ شامل چندین سرویس می باشد که باید با هم communicate  کنند؛ باید دید آیا سرویس های ما جهت قرار گرفتن در معماری از این نوع friendly هستند یا خیر.

همچنین ببینید

Serverless Architecture for an IoT solution xconf eu 2017

Serverless Architectures معماری Serverless که به عنوان یکی از Deployment Strategy های مورد در استفاده …

درس هایی که مایکروسرویس باید از موفقیت ها و شکست های SOA بگیرد.

درس هایی که مایکروسرویس باید از موفقیت ها و شکست های SOA بگیرد. یکی از …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن