آیا تیم SRE دارید ؟ چطور مسیر SRE و DevOps را شروع و تسهیل کنید

غالبا این سوال را از ما می‌پرسند که اجیاد تیم  تیم SRE باید چطور انجام شود

از آنجایی که مشتریان ما برای اندازه گیری موفقیت خود در پیاده کردن تیم SRE خود به چالشهایی برخورد می کنند در این پست چک لیستی که برای اعضای سازمان یا تیمی که مسئولیت هر نوع پایداری سرویس را برعهده دارند آماده کرده ام

این لیست برای زمانی که میخواهید تیم خود را به مدل SRE مهاجرت دهید بسیار مفید  خواهد بود
پیاده سازی مدل SRE و جاری سازی فرهنگ DevOPS در سازمان میتواند منفعت تیم و سرویس را به شرح زیر برای اعضای تیم به همراه  داشته باشد

• سطح بالاتری از پایداری سرویس 
• کاهش هزینه های عملیاتی
• ایجاد ارزش کاری بیشتر برای اعضای تیم

اما چطور میتوانید بگوید در این مسیر چقدر پیشرفت داشته یاد ؟
همچنانی که هیچ پاسخ سرراستی را نمیتوان به این سوال داد اما شما میتوانید در ادامه یک لیست غیر فراگیر را برای بررسی پیشرفت خود در این سفر داشته باشید  . همزمان با مسیر رو به رشد بلوغ تیم به مانند یک چک لیست سازمان یافته شوید. ایتم های چک لیست تقریبا به ترتیب زمانی بلوغ و رشد سازمان است اما در حقیقت نیاز های واقعی و اولیت های هر تیم میتواند متفاوت باشد.

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

SRE : حداقل های لازم برای تشکیل تیم

در ادامه به ۳ عنصر از آداب و روش های کلیدی SRE آورده شده است . اما این مورد میتواند بر اساس هر تیمی که مسئولیت سیستم های عملیاتی را فارغ از نام آنها تطابق داده شود قبل و یا همزمان با تشکیل و انتخاب نفرات تیم SRE

• برخی اهداف سطح سرویس یا SLO(Service Level Objective) تعریف شود ( این موضوع باید با مشارک تیم توسعه دهندگی و سطوح کسب و کاری سازمان اگر شما جزیی از آنها نیستید تهیه شده باشد)
• فرهنگ تشکیل جلسه  پس از واقعه بدون مقصر یابی  و نگارش گزارش  blameless postmortems وجود داشته باشد و سازمان از خطا ها و شکست های خود در حال یادگیری باشد
• فرایند هایی برای مدیریت رخداد های عملیاتی وجود داشته باشد و این فرایند میتواتند در سطح تمام سازمان باشد

تیم SRE برای شروع

اگر نه همه اما غالب تیم های SRE موفق در دنیا مانند تیم های گوگل آداب و روش و مشخصاتی که در ادامه آورده شده است را دارند. ما بصورت کلی این ها را برای پیاه های اساسی یک تیم SRE موثر میدانیم مگر اینکه دلایل خوبی برای عملی نشدن این موراد برای تیم و شرایط خاص وجود داشته باشد

• برنامه مشخصی برای جذب نیرو و استخدام تهیه و تصویب شود
  وقتی جذب نیرو انجام شد تیم ممکن است برای برخی سرویسها در حالی که بخشی از وضایف عملیاتی روزمره را بر عهده می گیرند بصوت onCall  شروع به فعالیت کنند (toil model )
• مستندات فنی برای فرایند انتشار نسخه ، راه اندازی سرویس و خارج از سرویس کردن محصول وجود داشته باشد ( اگر شرایط Failover را شامل می شود در مستند باید به فرایندهای مربوطه نیز اشاره شده باشد )‌
• فرایند انتشار نسخه ی با مدل  پردازش قناری (Canary Process for Release) همزمان با در نظر گرفتن SLO یا اهداف سطح سرویس بررسی شده باشد
• مکانیسم های Rollback در صورتی که لازم است وجود داشته باشد ( البته باید درک کنید که این یک قاعده غیر مبهم و دقیق باشد مثلا زمانی که اپلیکیشن های موبایل سرویس مد نظر را تشکیل می دهد
• یک Playbook , Runbook عملیاتی باید وجود داشته باشد حتی اگر کامل نباشد
• تئوری اجرای سناریو های اجرای بازی مبتنی بر نقش (Role Play ) برای تست Disater recover وجود داشته باشد و اجرا شود و حداقل سالانه اجرا شود
• SRE کارهای پروژه را برنامه ریزی و اجرا کند ، اگر چه ممکنت است در لحظه توسط تیم توسعه دهنده قابل مشاهده نباشد این مدل رفتار تیم SRE ممکن است باعث کاهش بار و تلاشهایی شوند که نیاز به جذب توسعه دهنده دارد

همچنین موارد زیر برای تیم های اس آر ای که تازه شروع میکنند جز Best Practice ها است اگراین عناوین وجود نداشته باشد نشانه سلامت کم تیم و مشکلات توسعه پایدار است

بار On-Call کافی به شکلی که بتوان شیوه نامه پاسخ به رخداد یا Incident response procedure را بصورت منظم ( مثلا هفتگی ) تمرین کرد

یک چارتر تیم SRE که توسط تیم مدیریتی فراتر از مدیریت SRE بازبینی و تایید شده باشد

جلسات منظم بین SRE و مدیریت توسعه محصولات برای گفتگ در خصوص مشکلات و اهداف و همچنین به اشتراک گذاری اطلاعات

برنامه ریزی و اجرای پروژه توسط تیمی متشکل از SRE و توسعه دهندگان صورت پذیرد به شکلی که کار SRE تیم و اثر مثبت آن برای رهبری مجموعه و تیم توسعه نرم افزار آشکار باشد