آیا درک نکته اصلی هنگام صحبت در مورد DevOps دشوار است؟ ما تشبیه های واضح، فرمول های قابل توجه و توصیه هایی از متخصصان را برای شما جمع آوری کرده ایم که حتی به افراد غیرمتخصص نیز کمک می کند تا به اصل مطلب برسند. در پایان، پاداش، DevOps خود کارمندان Red Hat است.
اصطلاح DevOps 10 سال پیش سرچشمه گرفت و از یک هشتگ توییتر به یک جنبش فرهنگی قدرتمند در دنیای فناوری اطلاعات تبدیل شده است، یک فلسفه واقعی که توسعه دهندگان را تشویق می کند کارها را سریعتر انجام دهند، آزمایش کنند و به جلو ادامه دهند. DevOps به طور جدایی ناپذیری با مفهوم تحول دیجیتال پیوند خورده است. اما همانطور که اغلب در مورد اصطلاحات فناوری اطلاعات اتفاق می افتد، در طول ده سال گذشته DevOps تعاریف، تفاسیر و تصورات نادرستی زیادی درباره خود به دست آورده است.
بنابراین، اغلب می توانید سوالاتی در مورد DevOps بشنوید، مانند اینکه آیا این همان چابک است؟ یا این روش خاصی است؟ یا فقط مترادف دیگری برای کلمه "همکاری" است؟
DevOps شامل مفاهیم مختلف زیادی است (تحویل مداوم، ادغام مداوم، اتوماسیون و غیره)، بنابراین تقطیر آنچه مهم است می تواند چالش برانگیز باشد، به خصوص زمانی که به موضوع علاقه دارید. با این حال، این مهارت بسیار مفید است، فرقی نمی‌کند که ایده‌های خود را به مافوق خود منتقل کنید یا صرفاً به کسی از خانواده یا دوستان خود در مورد کار خود بگویید. بنابراین، بیایید فعلاً تفاوت‌های اصطلاحی DevOps را کنار بگذاریم و روی تصویر بزرگ تمرکز کنیم.
DevOps چیست: 6 تعریف و تشابه
ما از کارشناسان خواستیم که ماهیت DevOps را تا حد امکان ساده و مختصر توضیح دهند تا ارزش آن برای خوانندگان با هر سطح دانش فنی روشن شود. بر اساس نتایج این مکالمات، ما برجسته‌ترین تشبیه‌ها و فرمول‌بندی‌های قابل توجه را انتخاب کرده‌ایم که به شما کمک می‌کند داستان خود را درباره DevOps بسازید.
1. DevOps یک جنبش فرهنگی است
Eveline Oehrlich، محقق ارشد می‌گوید: «DevOps یک جنبش فرهنگی است که در آن هر دو طرف (توسعه‌دهندگان نرم‌افزار و متخصصان عملیات سیستم فناوری اطلاعات) تشخیص می‌دهند که نرم‌افزار تا زمانی که کسی شروع به استفاده از آن نکند، مزایای واقعی به همراه ندارد: مشتریان، مشتریان، کارمندان، نه هدف. تحلیلگر موسسه DevOps بنابراین، هر دو طرف مشترکاً تحویل سریع و باکیفیت نرم‌افزار را تضمین می‌کنند.»
2. DevOps در مورد توانمندسازی توسعه دهندگان است.
"DevOps به توسعه دهندگان این امکان را می دهد که برنامه ها را داشته باشند، آنها را اجرا کنند و تحویل را از ابتدا تا انتها مدیریت کنند."
Jai Schniepp، مدیر پلتفرم‌های DevOps در شرکت بیمه Liberty Mutual می‌گوید: «معمولاً از DevOps به عنوان راهی برای سرعت بخشیدن به تحویل برنامه‌ها به تولید با ساخت و پیاده‌سازی فرآیندهای خودکار صحبت می‌شود. "اما برای من این یک چیز بسیار اساسی تر است." DevOps به توسعه دهندگان این امکان را می دهد که برنامه ها یا قطعات خاصی از نرم افزار را داشته باشند، آنها را اجرا کنند و تحویل آنها را از ابتدا تا انتها مدیریت کنند. DevOps سردرگمی مسئولیت را از بین می برد و همه افرادی را که در ایجاد یک زیرساخت خودکار و مبتنی بر توسعه دهندگان دخیل هستند راهنمایی می کند.
3. DevOps در مورد همکاری در ایجاد و ارائه برنامه ها است.
Gur Staf، رئیس و رئیس اتوماسیون کسب و کار دیجیتال در BMC می‌گوید: «به عبارت ساده، DevOps رویکردی برای تولید و تحویل نرم‌افزار است که در آن همه با هم کار می‌کنند.
4. DevOps یک خط لوله است
"مونتاژ نوار نقاله تنها در صورتی امکان پذیر است که همه قطعات با هم هماهنگ شوند."
Gur Staff ادامه می دهد: «من DevOps را با خط مونتاژ خودرو مقایسه می کنم. - ایده این است که تمام قطعات را از قبل طراحی و ساخته شوند تا بتوان آنها را بدون تنظیم فردی مونتاژ کرد. مونتاژ نوار نقاله تنها در صورتی امکان پذیر است که همه قطعات با هم قرار گیرند. کسانی که یک موتور را طراحی و می سازند باید در نظر داشته باشند که چگونه آن را روی بدنه یا قاب نصب کنند. کسانی که ترمز می سازند باید به فکر چرخ ها و ... باشند. همین امر در مورد نرم افزار نیز باید صادق باشد.
توسعه‌دهنده‌ای که منطق کسب‌وکار یا یک رابط کاربری ایجاد می‌کند باید در مورد پایگاه داده‌ای که اطلاعات مشتری را ذخیره می‌کند، اقدامات امنیتی برای محافظت از داده‌های کاربر، و نحوه عملکرد همه اینها زمانی که سرویس شروع به ارائه خدمات به مخاطبان بزرگ، شاید حتی چند میلیون دلاری کند، فکر کند. "
وادار کردن افراد به همکاری و فکر کردن در مورد بخش‌هایی از کار که دیگران انجام می‌دهند، به جای تمرکز صرف روی وظایف خود، بزرگترین مانع برای غلبه بر آن است. اگر بتوانید این کار را انجام دهید، شانس بسیار خوبی برای تحول دیجیتال خواهید داشت.
5. DevOps ترکیب مناسبی از افراد، فرآیندها و اتوماسیون است
جین گرول، مدیر اجرایی مؤسسه DevOps، یک تشبیه عالی برای توضیح DevOps ارائه کرد. به گفته او، «DevOps مانند یک دستور غذا با سه دسته اصلی مواد تشکیل دهنده است: افراد، فرآیند و اتوماسیون. بیشتر این مواد را می توان از مناطق و منابع دیگر گرفت: ناب، چابک، SRE، CI/CD، ITIL، رهبری، فرهنگ، ابزار. راز DevOps، مانند هر دستور غذای خوب، این است که چگونه می‌توان نسبت‌ها و ترکیب مناسبی از این مواد را برای افزایش سرعت و کارایی ایجاد و انتشار برنامه‌ها به دست آورد.»
6. DevOps زمانی است که برنامه نویسان مانند یک تیم فرمول 1 کار می کنند
"مسابقه از ابتدا تا انتها برنامه ریزی نشده است، بلکه برعکس، از پایان تا شروع برنامه ریزی شده است."
کریس شورت، مدیر ارشد بازاریابی پلتفرم ابری در Red Hat و ناشر خبرنامه DevOps'ish می‌گوید: «وقتی در مورد انتظارات از یک ابتکار DevOps صحبت می‌کنم، به یک تیم مسابقه‌ای NASCAR یا Formula 1 به عنوان مثال فکر می‌کنم. - رهبر چنین تیمی یک هدف دارد: گرفتن بالاترین مکان ممکن در پایان مسابقه با در نظر گرفتن منابع در دسترس تیم و چالش های پیش روی آن. در این صورت، مسابقه نه از ابتدا تا انتها، بلکه برعکس، از پایان تا شروع برنامه ریزی شده است. ابتدا یک هدف بلندپروازانه تعیین می شود و سپس راه های رسیدن به آن مشخص می شود. سپس آنها به وظایف فرعی تقسیم می شوند و به اعضای تیم واگذار می شوند.
تیم کل هفته قبل از مسابقه را صرف تکمیل پیت استاپ می کند. او تمرینات قدرتی و کاردیو را انجام می دهد تا در یک روز مسابقه طاقت فرسا در فرم بماند. برای حل هر گونه مشکلی که ممکن است در طول مسابقه ایجاد شود، با هم کار می کنند. به همین ترتیب، تیم توسعه باید مهارت انتشار مکرر نسخه‌های جدید را آموزش دهد. اگر چنین مهارت‌هایی دارید و یک سیستم امنیتی خوب کار می‌کنید، عرضه نسخه‌های جدید به تولید نیز بیشتر اتفاق می‌افتد. در این جهان بینی، افزایش سرعت به معنای افزایش ایمنی است.
شورت می‌افزاید: «مساله این نیست که «کار درست» را انجام دهیم، بلکه حذف هر چه بیشتر چیزهایی است که مانع رسیدن به نتیجه مطلوب می‌شوند. بر اساس بازخوردی که در زمان واقعی دریافت می کنید، همکاری کنید و تطبیق دهید. برای ناهنجاری ها آماده باشید و برای بهبود کیفیت تلاش کنید تا تأثیر آنها بر پیشرفت به سمت هدف خود را به حداقل برسانید. این چیزی است که در دنیای DevOps در انتظار ما است.
نحوه مقیاس بندی DevOps: 10 نکته از متخصصان
فقط DevOps و DevOps انبوه چیزهای کاملاً متفاوتی هستند. ما به شما خواهیم گفت که چگونه بر موانع در مسیر اول به دوم غلبه کنید.
برای بسیاری از سازمان ها، سفر به DevOps به راحتی و خوشایند آغاز می شود. تیم‌های کوچک پرشور ایجاد می‌شوند، فرآیندهای قدیمی با فرآیندهای جدید جایگزین می‌شوند و اولین موفقیت‌ها دیری نخواهد آمد.
بن گرینل، مدیر عامل و رئیس بخش دیجیتال در مشاوره نورث هایلند می گوید افسوس که این فقط یک زرق و برق کاذب است، یک توهم پیشرفت. بردهای اولیه مطمئناً دلگرم کننده هستند، اما به دستیابی به هدف نهایی یعنی پذیرش گسترده DevOps در سراسر سازمان کمکی نمی کنند.
به راحتی می توان دریافت که نتیجه فرهنگ تقسیم بین «ما» و «آنها» است.
بن گرینل توضیح می‌دهد: «اغلب، سازمان‌ها این پروژه‌های پیشگام را راه‌اندازی می‌کنند و فکر می‌کنند که راه را برای توسعه‌دهندگان اصلی هموار می‌کنند، بدون اینکه در نظر بگیرند که آیا دیگران می‌توانند یا مایل به دنبال کردن این مسیر باشند یا خیر». – تیم‌هایی برای اجرای چنین پروژه‌هایی معمولاً از «وارنگیان» با اعتماد به نفسی که قبلاً در جاهای دیگر کاری مشابه انجام داده‌اند، اما برای سازمان شما جدید هستند، استخدام می‌شوند. در عین حال، آنها تشویق می شوند تا قوانینی را که برای دیگران الزام آور باقی می ماند، بشکنند و از بین ببرند. به راحتی می توان دریافت که نتیجه، فرهنگ «ما» و «آنها» است که مانع از انتقال دانش و مهارت می شود.
"و این مشکل فرهنگی تنها یکی از دلایلی است که توسعه DevOps را دشوار می کند. استیو نیومن، موسس و رئیس Scalyr، گفت: تیم‌های DevOps با چالش‌های فنی فزاینده‌ای مواجه هستند که نمونه‌ای از شرکت‌های در حال رشد سریع در زمینه فناوری اطلاعات است.
«در دنیای مدرن، خدمات به محض ایجاد نیاز تغییر می‌کنند. استیو نیومن اضافه می کند که اجرای مداوم و پیاده سازی ویژگی های جدید عالی است، اما هماهنگ کردن این فرآیند و از بین بردن مشکلاتی که به وجود می آیند یک سردرد واقعی است. – در سازمان‌هایی که به سرعت در حال رشد هستند، مهندسان در تیم‌های چندکارهی برای حفظ دید تغییرات و اثرات آبشاری سطح وابستگی که ایجاد می‌کند، تلاش می‌کنند. علاوه بر این، مهندسان وقتی از این فرصت محروم می‌شوند خوشحال نمی‌شوند و در نتیجه درک اصل مشکلات پیش آمده برایشان دشوارتر می‌شود.»
چگونه می توان بر این چالش هایی که در بالا توضیح داده شد غلبه کرد و به سمت پذیرش انبوه DevOps در یک سازمان بزرگ حرکت کرد؟ کارشناسان به صبر توصیه می کنند، حتی اگر هدف نهایی شما سرعت بخشیدن به چرخه توسعه نرم افزار و فرآیندهای تجاری شما باشد.
1. به یاد داشته باشید که تغییر فرهنگ زمان می برد.
جین گرول، مدیر اجرایی موسسه DevOps: به نظر من، گسترش DevOps باید به اندازه توسعه چابک افزایشی و تکراری باشد (و به همان اندازه فرهنگ را لمس کند). Agile و DevOps بر تیم های کوچک تاکید دارند. اما با افزایش تعداد و ادغام این تیم‌ها، در نهایت افراد بیشتری روش‌های جدید کار را اتخاذ می‌کنند و در نتیجه تحول فرهنگی گسترده‌ای رخ می‌دهد.»
2. زمان کافی را صرف برنامه ریزی و انتخاب یک پلتفرم کنید
اران کینزبرونر، مبشر فنی ارشد در پرفکتو: تیم‌های DevOps ابتدا باید فرآیندها، ابزارها و مهارت‌های سنتی را ترکیب کنند و سپس به آرامی هر مرحله از DevOps را تقویت و تثبیت کنند. همه‌چیز با برنامه‌ریزی دقیق داستان‌های کاربر و جریان‌های ارزش شروع می‌شود، سپس با نوشتن نرم‌افزار و کنترل نسخه با استفاده از توسعه مبتنی بر ترانک یا سایر رویکردهای مناسب برای شاخه‌بندی و ادغام کدها، شروع می‌شود.
سپس مرحله یکپارچه سازی و آزمایش فرا می رسد، جایی که یک پلت فرم مقیاس پذیر برای اتوماسیون از قبل مورد نیاز است. اینجاست که برای تیم‌های DevOps مهم است که پلتفرم مناسبی را انتخاب کنند که متناسب با سطح مهارت و اهداف نهایی پروژه باشد.
مرحله بعدی استقرار به تولید است و این باید با استفاده از ابزارها و کانتینرهای ارکستراسیون کاملاً خودکار شود. داشتن محیط های مجازی در تمام مراحل DevOps (شبیه ساز تولید، محیط QA و محیط تولید واقعی) مهم است و همیشه از آخرین داده ها برای آزمایش ها برای به دست آوردن نتیجه گیری های مرتبط استفاده کنید. تجزیه و تحلیل باید هوشمند و قادر به پردازش داده های بزرگ با بازخورد سریع و عملی باشد.
3. احساس گناه را از مسئولیت خارج کنید.
گوردون هاف، تبشیر کلاه قرمزی: «ایجاد یک سیستم و فضایی که اجازه می دهد و آزمایش را تشویق می کند، مواردی را که به عنوان شکست های موفق در توسعه نرم افزار چابک شناخته می شوند، امکان پذیر می کند. این بدان معنا نیست که هیچ کس دیگری مسئول شکست نیست. در واقع، تشخیص اینکه چه کسی مسئول است، آسان‌تر می‌شود، زیرا «مسئول بودن» دیگر به معنای «ایجاد حادثه» نیست. یعنی جوهر مسئولیت از نظر کیفی تغییر می کند. چهار عامل مهم هستند: میزان اختلال، رویکردها، فرآیندهای تولید و مشوق‌ها. (شما می توانید در مقاله گوردون هاف «درس های DevOps: 4 جنبه از آزمایش های سالم» درباره این عوامل بیشتر بخوانید.)
4. مسیر رو به جلو را پاک کنید
بن گرینل، مدیر عامل و رئیس بخش دیجیتال در مشاوره نورث هایلند: برای دستیابی به مقیاس، توصیه می‌کنم برنامه «پاکسازی مسیر» را همراه با پروژه‌های پیشگام راه‌اندازی کنید. هدف این برنامه پاکسازی زباله هایی است که پیشگامان DevOps از خود به جا می گذارند، مانند قوانین منسوخ شده و مواردی از این قبیل، به طوری که مسیر رو به جلو روشن باقی بماند.
از طریق ارتباطی که فراتر از گروه پیشگام است، با تجلیل گسترده از موفقیت‌های روش‌های جدید کار، به افراد حمایت و حرکت سازمانی بدهید. افرادی را که در موج بعدی پروژه های DevOps درگیر هستند و در مورد استفاده از DevOps برای اولین بار عصبی هستند، مربی کنید. و به یاد داشته باشید که این افراد با پیشگامان بسیار متفاوت هستند.»
5. ابزارها را دموکراتیک کنید
استیو نیومن، بنیانگذار و رئیس Scalyr: ابزارها نباید از دید مردم پنهان باشند، و یادگیری آنها برای هر کسی که مایل به صرف وقت است باید نسبتاً آسان باشد. اگر توانایی جستجوی گزارش‌ها محدود به سه نفر باشد که «گواهینامه» برای استفاده از یک ابزار دارند، شما همیشه حداکثر سه نفر را برای رسیدگی به مشکل در دسترس خواهید داشت، حتی اگر یک محیط محاسباتی بسیار بزرگ دارید. به عبارت دیگر، در اینجا یک گلوگاه وجود دارد که می تواند منجر به عواقب جدی (تجاری) شود.»
6. ایجاد شرایط ایده آل برای کار تیمی
تام کلارک، رئیس سکوی مشترک در ITV: "شما می توانید هر کاری را انجام دهید، اما نه همه چیز را به یکباره. بنابراین اهداف بزرگ تعیین کنید، از کوچک شروع کنید و با تکرارهای سریع به جلو حرکت کنید. با گذشت زمان، برای انجام کارها شهرت پیدا می کنید، بنابراین دیگران نیز مایلند از روش های شما استفاده کنند. و نگران ایجاد یک تیم بسیار موثر نباشید. در عوض، شرایط کاری ایده‌آل را برای افراد فراهم کنید و کارایی را به دنبال خواهد داشت.»
7. تابلوهای Conway's Law و Kanban را فراموش نکنید
لوگان دایگل، مدیر تحویل نرم افزار و استراتژی DevOps در CollabNetVersionOne: درک عواقب قانون کانوی بسیار مهم است. به عبارت ساده من، این قانون بیان می‌کند که محصولاتی که ایجاد می‌کنیم و فرآیندهایی که برای انجام آن استفاده می‌کنیم، از جمله DevOps، ساختاری مشابه سازمان ما دارند.
اگر سیلوهای زیادی در یک سازمان وجود داشته باشد و کنترل بارها هنگام برنامه ریزی، ساخت و انتشار نرم افزار تغییر کند، اثر مقیاس گذاری صفر یا کوتاه مدت خواهد بود. اگر یک سازمان تیم های متقابل عملکردی را حول محصولاتی ایجاد کند که بودجه آنها با تمرکز بازار تامین می شود، آنگاه شانس موفقیت به طور چشمگیری افزایش می یابد.
یکی دیگر از جنبه های مهم مقیاس بندی، نمایش تمام کارهای در حال انجام (WIP، پیشرفت کار) بر روی بردهای Kanban است. وقتی یک سازمان مکانی دارد که مردم می توانند این چیزها را ببینند، همکاری را به شدت تشویق می کند، که تأثیر مثبتی بر مقیاس بندی دارد.
8. به دنبال جای زخم های قدیمی باشید
Manuel Pais، مشاور DevOps و یکی از نویسندگان Team Topologies: «برداشتن تمرین‌های DevOps فراتر از خود Dev و Ops و تلاش برای اعمال آنها در عملکردهای دیگر، به سختی یک رویکرد بهینه است. این مطمئناً تأثیری خواهد داشت (مثلاً با خودکار کردن کنترل دستی)، اما اگر با درک فرآیندهای تحویل و بازخورد شروع کنیم، می‌توان به چیزهای بیشتری دست یافت.»
اگر در سیستم فناوری اطلاعات یک سازمان زخم‌های قدیمی وجود داشته باشد - رویه‌ها و مکانیسم‌های مدیریتی که در نتیجه حوادث گذشته پیاده‌سازی شده‌اند، اما ارتباط خود را (به دلیل تغییرات در محصولات، فناوری‌ها یا فرآیندها) از دست داده‌اند - قطعاً باید حذف شوند. به جای خودکارسازی فرآیندهای ناکارآمد یا غیرضروری، هموارسازی شود.»
9. گزینه های DevOps را پرورش ندهید
آنتونی ادواردز، مدیر عملیات Eggplant: DevOps یک اصطلاح بسیار مبهم است، بنابراین هر تیم نسخه مخصوص خود را از DevOps دارد. و وقتی یک سازمان ناگهان 20 نوع DevOps داشته باشد که خیلی با هم هماهنگ نیستند، هیچ چیز بدتر نیست. برای هر یک از سه تیم توسعه غیرممکن است که رابط کاربری خاص خود را بین توسعه و مدیریت محصول داشته باشند. همچنین محصولات نباید انتظارات منحصر به فرد خود را برای رسیدگی به بازخورد در هنگام انتقال به یک شبیه ساز تولید داشته باشند. در غیر این صورت، هرگز نمی‌توانید DevOps را مقیاس‌بندی کنید.»
10. ارزش تجاری DevOps را تبلیغ کنید
استیو نیومن، بنیانگذار و رئیس Scalyr: برای تشخیص ارزش DevOps کار کنید. بیاموزید و در مورد مزایای کاری که انجام می دهید صحبت کنید. DevOps یک صرفه جویی باورنکردنی در زمان و پول است (فقط فکر کنید: زمان از کار افتادگی کمتر، میانگین زمان کوتاه تر برای بازیابی)، و تیم های DevOps باید به طور خستگی ناپذیر بر اهمیت این ابتکارات برای موفقیت تجاری تأکید کنند (و موعظه کنند). به این ترتیب می توانید دایره پیروان را گسترش دهید و نفوذ DevOps را در سازمان افزایش دهید.
پاداش
بر DevOps خود ما در 13 سپتامبر وارد بازار می شود - بله، Red Hat، به عنوان یک تولید کننده نرم افزار، تیم ها و تمرینات DevOps خود را دارد.
مهندس ما مارک بیرگر، که خدمات اتوماسیون داخلی را برای گروه‌های دیگر در سراسر سازمان توسعه می‌دهد، داستان خود را به زبان روسی خالص تعریف می‌کند - اینکه چگونه تیم Red Hat DevOps برنامه‌ها را از محیط‌های مجازی Hat Virtualization که توسط Ansible مدیریت می‌شوند به یک فرمت کانتینر کامل منتقل کردند. پلت فرم OpenShift
اما این همه ماجرا نیست:
هنگامی که سازمان‌ها بارهای کاری را به کانتینرها منتقل کردند، روش‌های سنتی نظارت بر برنامه‌ها ممکن است کار نکنند. در گفتار دوم انگیزه خود را از تغییر نحوه ورود به سیستم توضیح خواهیم داد و ادامه مسیری را که ما را به روش های مدرن ثبت و نظارت سوق داد، نشان خواهیم داد.
منبع: www.habr.com