چند روش ساده برای گسترش فرهنگ DevOps

1398/04/26
امروزه اصطلاحات جدیدی مانند DevOps و پایبند بودن به آن در شرکت های بزرگ مطرح می شود. اما شاید بسیاری از مردم تفاوت DevOps و Continuous Delivery را نداند یا آن ها را به اشتباه به جای هم بکار ببرند. با توجه به تعریف موجود در Wikipedia، DevOps و Continuous Delivery با یکدیگر تداخل معنی دارند، هر چند در همه به این موضوع اشاره شده است که برای تحویل پیوسته (Continuous Delivery) باید با DevOps آشنا باشیم. در این پست با چند دیدگاه ساده برای راه اندازی سریع DevOps آشنا خواهیم شد.

سهامداران را در آموزش DevOps شریک کنید

اجرای DevOps امری سخت است، به خصوص زمانی که پای یک سازمان یا شرکت بزرگ در میان باشد. توجیه استفاده از DevOps و اینکه همه کارکنان سازمان متوجه ارزش آن شوند، نیازمند تلاش بسیار زیادی است. یکی از وظایف ما در قبال DevOps این است که کارکنان یک سازمان را آموزش دهیم تا به شکل کامل متوجه مفهوم و ارزش آن و تاثیر مستقیمش بر کسب و کار شوند. در واقع DevOps ایجاد ارزش مشتری و نوعی سرمایه گذاری در IT است.
بهترین راه حل برای تفهیم و اجرای یک موضوع جدید، آموزش پیوسته است. به شکل کلی هر گاه امری به شکل ادامه دار و تدریجی انجام پذیرد، این موضوع تضمین اجرای آن خواهد بود. آموزش پیوسته نوعی دیگر از "Continuous X" است که در آن به جای X می توان هر عبارتی را قرار داد. تاثیر اصلی این عبارت این است که فرهنگ را عوض خواهد کرد و برای تغییر فرهنگ حاکم بر سازمان، می بایست تمام افراد دخیل، با فرهنگ و برتری های DevOps و Continuous Delivery آشنا شوند.
 

از تولید ابزارهای کوچک شروع کنید

این یک حقیقت است که تولید و ساخت ابزارهای کوچک بسیار سریع تر از ابزارهای بزرگ است. همچنین این ابزارها در نگهداری، پشتیبانی و عملیات تست نیز ساده تر هستند. پس به چه علت برنامه نویسان باهوش هنوز در حال گسترش و تولید نرم افزارهای بزرگ هستند؟
"اولین باری که به عنوان یک C# Developer مشغول به کار شدم، احساس بسیار خوبی از رساندن پروژه به Deadline داشتم. مایل بودم به همه مسئولان بالادستی این موضوع را ثابت کنم که توانسته ام مشکلات ابزاری که تعداد زیادی از همکاران طی سال های زیاد موفق به رفع مشکلات آن نشده بودند را کنترل کنم. مشکل حل شده در نرم افزار بسیار سخت بود و تصور می کردم با ویژگی هایی که در سیستم قرار داده ام دیگر امور مشتری و کاربران سیستم راحت و ساده انجام خواهد شد. البته همه اینها تنها تا زمانی دوام داشت که کار بر روی وب سایت قرار گرفت."
فکر می کنم هر برنامه نویسی در نقطه ای از تجربه کاری خود با چنین موضوعی مواجه خواهد شد. ممکن است در چنین مواقعی برنامه نویس خود را مسبب کلیه مشکلات دانسته و خود را سرزنش کند یا سال ها بعد، ابزار را مقصر اصلی بداند! اما امروزه برای این سوال یک پاسخ مناسب وجود دارد. در سریع ترین زمان ممکن، برنامه های کوچک و قابل نگهداری تولید نمایید و از امروز نحوه نگرش و کارکرد خود را تغییر دهید.


از یک ابزار آنالیز کد ایستا استفاده نمایید

کیفیت همیشه مهم است، به خصوص زمانی که می تواند رویه ها به شکل خودکار انجام پذیرد. در نرم افزار نیز هر کدی که در Repository پروژه Commit می شود ممکن است به عنوان کد نسخه اصلی استفاده شود، پس کیفیت هر کد نگارش شده ای در پروژه مهم خواهد بود.
همواره از ابزارهای آنالیز کد ایستا (Static Code Analysis) استفاده کنید تا کیفیت کار خود را افزایش دهید. بررسی امنیت، تمیز بودن کد و ... که شاید بسیار زمانبر باشد را بر عهده یک ابزار بگذارید.
نمونه های زیادی برای این نوع ابزارهای آنالیز وجود دارد، به طور مثال، ابزار ارائه شده در https://www.codacy.com می تواند به شکلی یکپارچه در روند کاری قرار گیرد و کدهای شما را از حیث امنیت، کیفیت نگارش و ... بررسی نماید.


فرایندها را شفاف کنید

من لازم دارم همه چیز را بدانم! من مایل هستم به شکلی پیوسته و ادامه دار تمام رویه ها را بهبود ببخشم. شفافیت در هر چیزی برای کار من لازم است. مثال های گفته شده اگر چه کمی نمایشی هستند اما واقعیت دارند. باید متوجه این باشیم که چگونه با یکدیگر کار می کنیم. سهامداران می بایست تمام نقاط قوت و ضعف فرآیندی تیم را بدانند. در چنین محیط شفافی تنها می توان به وضوح گفت چه کمبودهایی در تیم وجود دارد، چه بخش هایی اضافه یا چه موضوعاتی نیازمند تغییر است.
یکی از روش های ساده و شناخته شده برای این موضوع، نگاه اجمالی بر وظایف در حال اجرا و نظارت بر نحوه عملکرد انجام دهندگان آن است. ممکن است یک تخته Scrum داشته باشید یا از Kanban استفاده نمایید. این موضوع یک قدم بسیار کوچک در حرکت به سمت این شفافیت خواهد بود. اما سهامداران با گذشت سریع زمان و کمبود وقت، آیا فرصت بررسی نحوه عملکرد و رفتار تیم را در هنگام مواجه شدن با مشکلات دارند؟ به گمانم خیر و بیشتر در چنین مواقعی در مورد اصلاحات ساختاری صحبت می شود تا رفع مشکل. اگر کلیه فرایندها بر همه اشخاص یک سازمان آشکار باشد، زمان به شکل هوشمندانه تری صرف شده و مشکل سریع تر رفع می گردد.
برای هر پروژه فضایی داشته باشید که در آن همه چیز درباره ساختار، جزییات و ابزارها به شکل ساده توضیح داده شده باشد. هر چیزی که در هنگام مواجه شدن با اشکال مورد نیاز است، می بایست آنجا یافت شود. ممکن است برای ساخت چنین محیطی به تنهایی اقدام کنید. نکته مثبت در تولید اسناد این است که نقاط نیازمند تقویت در ابزار به وضوح در آن مشخص است. ممکن است هر کارمندی موردی را ببیند که شما در طول پروژه به آن توجه نکرده باشید. کل رویه های سیستم را به شکل سند شده نگهداری کنید. هر چند در مواقعی نادر، اما بسیار مهم، قدردان این عملیات خواهید شد.
 

تا جایی که می توانید اندازه گیری کنید

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

ارزش را شفاف کنید

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


موفقیت را جشن بگیرید

انسان ها و مردم. همه چیز درباره همین عبارت است. شاید کل دلیل اینکه کار می کنیم توجه به نیاز افراد است. اعتقاد دارم زمانی شغل خود را عوض می کنیم تنها برای روبرو شده با رقابت های جدید نیست، بلکه با افرادی که  با آن ها کار می کنیم احساس ارتباط قوی نداریم. همکاران می توانند دوستان واقعی باشند، جزیی از یک خانواده. شاید به دلیل همین اهمیت، بخش عمده ای از DevOps درباره افرادی است که با آن ها کار می کنیم و اینکه چگونه با آن ها در تعامل هستیم. هدف نهایی هر تیم این است که به آنچه در توان تیم است برسیم، شاید کم و شاید هم زیاد ولی مسلماً می بایست با همکاران خود دوست و شاد بمانیم.
  • برای شام با همکاران بیرون بروید
  • از تک تک اعضای تیم بابت کارشان قدردانی کنید.
  • با انعطاف به اعضای تیم پاداش بدهید. با اعتماد کردن در سپردن وظایف و ...


از اپراتورها دعوت کنید

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


هر بار تنها یک امکان جدید به سیستم اضافه کنید

مورفی می گوید: "هر چیزی که می تواند اشتباه شود، اشتباه خواهد شد" و مسلماً هر یک از ما این موضوع را بارها تجربه کرده ایم. فرض کنید در یک لحظه 2 ابزار مختلف را Publish می کنید و به یک باره کل سیستم از دسترس خارج خواهد شد موضوعی که در نگاه اول اصلاً قابل باور نیست، سیستم کاملاً تست شده است اشکال از کجاست؟ شاید به عنوان یک برنامه نویس با تجربه و خوش شانس بتوانیم مشکلات را به شکلی سریع پیدا کنیم اما در سازمان های بزرگ چنین مواردی می تواند به یک کابوس تبدیل شود. با مشتریان خود صحبت کرده و آن ها را متقاعد کنید که "در یک لحظه تنها یک کار انجام می دهید". تنها یک تغییر را در یک لحظه بر روی سرور قرار دهید. با آرامش و در سایه ای امن رفتار کنید.


کلام آخر

مطمئناً اجرای تمام موارد فوق در یک زمان غیر ممکن است. در ابتدا تنها یک موضوع را انتخاب کرده و بر روی آن مانور دهید، موضوعی که احساس می کنید در آن موفق تر خواهید شد.
 
User Avatar
نویسنده : علی هریسچیان
امتیاز شما :

دیدگاه کاربران



ارسال پیام



 Security code