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

چون خود ویدیو به صورت مکالمه‌ی بین دو نفره و من مستقلا در مورد خود موضوع می‌خوام بنویسم کمی متفاوت میشه این متن از ویدیو. ولی تلاش می‌کنم دخل و تصرفی تو خود بحث نداشته باشم و صرفا بعضی جاها توضیحات بیشتری بدم.

دواپس چیه؟

قدیما (نه لزوما از لحاظ زمانی) توسعه‌دهنده‌ها بدون در نظر گرفتن مسائل مربوط به اجرای کد و نگهداری از کدهای در حال اجرا و زیرساخت‌های مربوط بهش، سعی داشتند تا فقط روی توسعه‌ی محصول تمرکز کنن و با سرعت بیشتری قابلیت‌های جدید به محصول اضافه کنن.

تیم‌های عملیاتی (Operation teams) هم تمرکزشون روی قابل اطمینان بودن خدمات و بالا نگه داشتن کدهای در حال اجرا بود.

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

موانع بین تیم‌های توسعه و عملیات

https://youtu.be/uTEL8Ff1Zvk?t=38s

دواپس که از ترکیب دو کلمه‌ی Development و Operations به وجود اومده، یک فرهنگه که شامل یک سری راه و روشه تا اون دیوار فرضی بین توسعه‌دهند‌ه‌ها و عملیاتی‌ها و حتی سایر تیم‌ها رو از بین ببره. دواپس رو میشه به پنج قسمت کلیدی شکوند.

  • کاهش مرزبندی‌های سازمانی؛ با از بین بردن دیوارهای فرضی بوجود اومده بین تیم‌ها می‌تونیم همکاری و بازدهی رو افزایش بدیم.
  • پذیرفتن خراب شدن به عنوان یه اتفاق عادی؛ کامپیوترها ذاتن قابل اطمینان نیستن و در نتیجه نمیشه ازشون انتظار بی‌نقص بودن داشت. و وقتی انسان‌ها رو هم وارد سیستم می‌کنیم بی‌نقص نبودن حتا جدی‌تر میشه.
  • پیاده‌سازی تغییر دادن به صورت آهسته و پیوسته؛ نه تنها تغییرات کوچیک و افزایشی برای مرور و بررسی ساده‌تر هستن، بلکه باعث میشه که اگر یک تغییر این مدلی، باعث ایجاد مشکل در محیط پروداکشن بشه، زمانی که برای درست کردنش لازمه، کمتر بشه. چون به سادگی میشه برش گردوند به حالت قبل.
  • استفاده‌ی حداکثری از ابزارها و اتوماسیون.
  • اندازه‌گیری همه چیز؛ اندازه‌گیری نکته‌ی حیاتیه برای موفقیت! و برای تشخیص اینکه چهار ستون اول (قاعده‌های قبل) موفقیت‌آمیز بوده یا نه، هیچ راهی جز اندازه‌گیری وجود نداره.
پنج قسمت کلیدی دواپس

https://youtu.be/uTEL8Ff1Zvk?t=2m15s

اس‌آر‌ای چیه؟

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

کلاس اس‌آر‌ای دواپس رو پیاده‌سازی می‌کنه

https://youtu.be/uTEL8Ff1Zvk?t=2m45s

پس با این وجود اس‌آر‌ای باید پنج نکته‌ای که دواپس میگه رو اجرا کنه. از اونجایی که اس‌آر‌ای راه حل گوگله بیاید جزئی‌تر ببینیم چجوری این کار رو انجام می‌ده.

  • کاری که اس‌آر‌ای برای از بین بردن مرزبندی‌های سازمانی انجام میده، به اشراک‌گذاری مالکیت و مسئولیت پروداکشن بین تیم‌های اس‌آر‌ای و توسعه‌دهنده‌هاست. همچنین از ابزارهای یکسانی استفاده میشه تا دید و راه و روش همه در برخورد با پروداکشن یکسان باشه.
  • در مورد پذیرش خراب شدن، اس‌آر‌ای بدون سرزنش افراد، از کالبدشکافی‌ (postmortem) اتفاق استفاده می‌کنه تا مطمئن بشه خرابی که تو سیستم به وجود اومده دقیقا به همون شکل دوباره تکرار نشه. همچنین با استفاده از یک مفهوم به اسم بودجه‌ی خطا تعیین می‌کنه که یک سیستم تا چه حد می‌تونه دچار خرابی و مشکل بشه؛ که این باعث میشه تا خراب شدن به عنوان یک اتفاق عادی دیده بشه.
  • برای اجرای تغییرات آهسته و پیوسته از تکنیک انتشار قناری استفاده میشه که قبل از اینکه یه تغییر رو به صورت کلی و برای همه‌ی کاربرها منتشر بشه، فقط برای درصدی از اونا منتشر بشه و در صورتی که دچار مشکل شد بدون اینکه همه تحت تاثیر قرار بگیرن سریع برگرده به حالت قبل.
  • و تا جای ممکن سعی میشه تا کارهای دستی کم بشه. برای همین کارهای سخت و تکراری رو باید اندازه‌گیری کرد و در انتها سعی بشه تا اون کارها خودکار بشن.
  • و در نهایت اندازه‌گیری کارهای سخت و تکراری، اندازه‌گیری سلامت و قابل اطمینان بودن سیستم‌ها مثال‌هایی برای اندازه‌گیری کردن همه چیزه.

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

پس بذارید تا در قسمت بعد که در مورد چیستی و تفاوت SLO، SLI و SLA و تاثیرشون تو موفق شدن اس‌آرای هست بیشتر به این مسئله بپردازیم.

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