مروری بر کنفرانس DevOpsDays مسکو: بینش از 6 گزارش

سومین کنفرانس در 7 آذر برگزار شد DevOpsDays مسکو، توسط جامعه DevOps Moscow با پشتیبانی Mail.ru Cloud Solutions سازماندهی شده است. علاوه بر ارائه‌های متخصصان برجسته DevOps، شرکت‌کنندگان می‌توانند در گفتگوهای کوتاه انگیزشی لایتنینگ، کارگاه‌های آموزشی شرکت کنند و در فضاهای باز ارتباط برقرار کنند.

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

داخل:

1. Baruch Sadogursky، JFrog: "اجازه دهید نرم افزار مانند مایع از فروشنده به کاربر جریان یابد"
2. Pavel Selivanov، Southbridge: "Dev و Ops یک وظیفه مشترک دارند - ساختن محصولی که کار کند."
3. ولادیمیر اوتراتنکو، گروه خرده فروشی X5: "DevOps در Enterprise توسعه بدون درد و آتش است"
4. سرگئی پوزیرف، فیس بوک: "مهندس تولید به خدمات به عنوان یک کل اهمیت می دهد: به طوری که هم کاربران و هم توسعه دهندگان اوقات خوبی داشته باشند."
5. میخائیل چینکوف، AMBOSS: "یک بخش نمی تواند مسیر DevOps را دنبال کند، کل شرکت باید آن را دنبال کند."
6. علاقه مندان به توسعه DevOps Rosbank: "1000 روز برای پیاده سازی DevOps در یک شرکت خونین"

1. Baruch Sadogursky، JFrog: "اجازه دهید نرم افزار مانند مایع از فروشنده به کاربر جریان یابد"

خرابی های به روز رسانی نرم افزار هر ساعت و برای همه اتفاق می افتد. در اینجا فقط یک داستان ترسناک از این سخنرانی آورده شده است: Knight Capital در یک ساعت پس از یک آپدیت ناموفق، 440 میلیون دلار از دست داد.

باروخ در مورد الگوهای به روز رسانی مداوم DevOps صحبت کرد که به جلوگیری از شکست و نفرت کاربر کمک می کند:

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

به روز رسانی از طریق هوا - پیوسته بهتر در غیر این صورت، مانند توسعه دهندگان جگوار خواهد بود: به دلیل یک اشکال در سیستم ترمز، که نمی تواند از طریق هوا به روز شود، خودروها مجبور به فراخوانی از فروش شدند. دردناک و گران بود.

به روز رسانی مداوم - به محض آماده شدن یک ویژگی جدید، نرم افزار را به طور مداوم به روز کنید. با به‌روزرسانی‌های نادر، ویژگی‌ها با هم گروه‌بندی می‌شوند. مانند تسلا، به‌روزرسانی‌ای که قرار بود ترمز تصادفی را برطرف کند، منتظر به‌روزرسانی بازی شطرنج بود.

استقرار خودکار - افراد را با ماشین ها جایگزین کنید، زیرا افراد در انجام کارهای معمول بد هستند.

به روز رسانی های مکرر - به شما در ایجاد یک عادت و رهایی از ترس کمک می کند. به‌روزرسانی‌های نادر به رویدادهای اضطراری تبدیل می‌شوند.

اطلاع از وضعیت دستگاه - آزمایش به روز رسانی، نه نصب از ابتدا. این مهم است زیرا به‌روزرسانی‌ها ممکن است بسته به وضعیت دستگاه رفتار متفاوتی داشته باشند.

قناری رها می کند - به روز رسانی ها را برای تعداد کمی از کاربران منتشر کنید و مشاهده کنید. این باعث کاهش آسیب در صورت بروز مشکل می شود.

به روز رسانی بدون در دسترس نبودن - به مشتریان اجازه دهید فقط ویژگی‌های جدید را متوجه شوند و در حین ارائه به‌روزرسانی، چندین هفته بدون خدمات باقی نمانند.

ما با باروخ سادوگورسکی در مورد تفاوت دیدگاه DevOps در روسی و غربی صحبت کردیم، اینکه آیا Cloud به زودی همه چیز را برای ما انجام خواهد داد و آیا همه سرویس های نرم افزاری به طرح aaS خواهند رفت - مصاحبه را تماشا کنید:

2. Pavel Selivanov، Southbridge: "Dev و Ops یک وظیفه مشترک دارند - ساختن محصولی که کار کند."

پیاده سازی Kubernetes به دستیابی به DevOps کمکی نمی کند و برعکس، می تواند همه چیز را خراب کند. پاول توضیح داد که چرا فناوری (حتی جالب ترین) نمی تواند همه مشکلات شما را حل کند:

پیچیدگی پروژه از کد فراتر رفته است. قبلاً یک برنامه پیچیده وجود داشت: تعامل در پروژه و توسعه پیچیده، اما یک ساختار ساده - مدیر آن را مستقر کرد، همه چیز کار می کند. ما به سمت میکروسرویس ها رفتیم: هر سرویس یک برنامه کاربردی ساده، ارتباط با استفاده از پروتکل های استاندارد و توسعه سریع است، اما ساختار پروژه پیچیده تر شده است. پیچیدگی یک پروژه با معماری میکروسرویس از بین نرفته است - از کد فراتر رفته است. اکنون مهندس DevOps مسئول آن است.

توسعه دهندگان پس از اجرای DevOps تغییراتی را نمی خواهند. در نتیجه، جریان کار با Kubernetes همچنان شبیه پرتاب وظایف از Dev به Ops بر روی دیوار است، اما نه استعاری - Git به چنین دیواری تبدیل می‌شود. توسعه دهنده کد را در آنجا قرار می دهد و مانند قبل کار می کند و ادمین ها Kubernetes، CI/CD و هر چیز دیگری دارند.

با این حال، توسعه دهندگان باید تغییرات را بپذیرند. شرایطی که توسعه‌دهندگان نمی‌دانند ادمین‌ها چه می‌کنند، و ادمین‌ها نمی‌دانند چه اتفاقی برای توسعه‌دهندگان می‌افتد، مشکلاتی را ایجاد می‌کند.

اگر چیزی برای توسعه دهندگان تغییر نکرده باشد، آنها متوجه نمی شوند که عملکرد برنامه مسئولیت آنهاست - ترفندهای فنی مختلف کار نمی کنند.

با ظهور DevOps و Kubernetes، چیزهای زیادی در توسعه تغییر خواهد کرد. توسعه دهندگان باید در Ops صلاحیت داشته باشند و بالعکس. این متخصصان مهارت های خاص خود را دارند، اما باید از کار یکدیگر آگاه باشند. Dev و Ops باید قبل از اجرای Kubernetes با هم دوست باشند، در غیر این صورت آنچه را که دارید خواهید شکست.

پاول سلیوانوف در مورد آنچه که در 5 سال آینده برای Kubernetes اتفاق می‌افتد صحبت کرد و یک استارت‌آپ مدرن باید روی آن پشته فناوری بسازد - مصاحبه را تماشا کنید:

3. Vladimir Utratenko، گروه خرده فروشی X5: "DevOps در Enterprise توسعه بدون درد و آتش است"

شرکت‌ها زمانی به تحول DevOps می‌رسند که متوجه می‌شوند توسعه بسیار کند است و با واقعیت‌ها مطابقت ندارد، آنها تمایل دارند بهتر توسعه پیدا کنند و سریع‌تر عرضه شوند.

ولادیمیر توضیح داد که چگونه این اتفاق می افتد و چه چیزی گرفتار است:

1. ابتدا، شرکت ها یک مهندس DevOps را استخدام می کنند. این یک مدیر ارشد سیستم است، او در استقرار یک نسخه برای تولید، استانداردسازی محیط توسعه، راه اندازی زیرساخت، شناسایی و رفع مشکلات مختلف، خودکارسازی فرآیندها و سایر وظایف فنی شرکت دارد.
2. سپس یک مهندس DevOps دیگر کافی نیست و شرکت یک تیم DevOps را استخدام می کند. این یک مرکز صلاحیت است که تلاش های مهندسان متفاوت را سازماندهی می کند و به آنها اجازه می دهد در یک جهت متمرکز شوند.
3. در واقع، مهندس DevOps و تیم های DevOps ضد الگوهای تحول DevOps هستند. از آنجایی که DevOps در مورد شیوه ها و فرهنگ است، علاوه بر این، پیاده سازی DevOps در شرکت های فناوری (SRE، مهندسی تولید) وجود دارد.

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

هنگامی که یک کسب و کار وارد بازی می شود و در DevOps سرمایه گذاری می کند، چندین سناریو ممکن است: همه چیز در زمان برخاستن از بین می رود. به عنوان SRE/Production Engineering یا Embedded Operas باقی خواهد ماند. زمانی که فرآیندها بر اساس معیارهای تجاری باشد، به BizOps منتقل می شود.

ولادیمیر اوتراتنکو به ما گفت که DevOps در یک شرکت واقعا چقدر "خونین" است و چگونه اقدامات در خرده فروشی بزرگ اجرا می شود - مصاحبه را تماشا کنید:

4. سرگئی پوزیرف، فیس بوک: "مهندس تولید به خدمات به عنوان یک کل اهمیت می دهد: به طوری که هم کاربران و هم توسعه دهندگان اوقات خوبی داشته باشند."

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

سرگئی گفت که یک مهندس تولید در فیس بوک چه می کند:

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

5. میخائیل چینکوف، AMBOSS: "یک بخش نمی تواند مسیر DevOps را دنبال کند، کل شرکت باید آن را دنبال کند."

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

تفاوت در درک DevOps. دووپ های متعارف، همانطور که انجیلیان آن را می بینند، بر 5 ستون استوار است:

• فرهنگ - تمرکز بر مردم و همکاری؛
• اتوماسیون - تفویض روال به گردش کار؛
• ناب - تأکید بر ارائه ارزش به کاربر؛
• به اشتراک گذاری - تبادل مستمر دانش؛
• معیارها و دریافت بازخورد با استفاده از آنها.

شرکت ها معمولاً فقط بر اتوماسیون و ارائه ارزش به کاربر تمرکز می کنند. اما فرهنگ، اشتراک دانش و معیارهای DevOps برای ردیابی توسعه در پس‌زمینه محو می‌شوند.

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

چرا ما هنوز DevOps نیستیم؟ دو مشکل کلیدی وجود دارد. در Enterprise توسعه آهسته سازمان وجود دارد، مشکلات با تغییر بردار در ذهن هزاران کارمند وجود دارد. در استارتاپ ها کمبود منابع دانش و مشکل تخصیص منابع برای تحول وجود دارد.

مراحل توسعه DevOps در یک شرکت:

• اولی زیرساخت در فضای ابری است، اما هیچ کس به جز یک یا دو ادمین نمی داند چگونه کار می کند.
• دوم، زیرساخت شفاف و قابل درک برای همه مهندسان است، اما فرآیندها ساده نیست.
• سوم - مهندسان به طور مستقل خدمات زنده را راه اندازی و تعمیر می کنند.
• چهارم - مهندسان به صورت اختیاری به زیرساخت اصلی، کد شفاف در ابر، استقرار با دکمه کمک خواهند کرد.

طرح ایده آل این است که همه به یکسان به زیرساخت دسترسی داشته باشند، همه مهندسان به محصول دسترسی داشته باشند و بفهمند که چه کاری انجام می دهند.

با بسته شدن همه گشتالت‌های فرهنگی و فنی، تحول DevOps این شرکت، بازخوردهای معیارهای کسب‌وکار و پلتفرم را در نظر می‌گیرد.

6. علاقه مندان به DevOps Rosbank: "1000 روز برای پیاده سازی DevOps در یک شرکت خونین"

یوری بولیچ، دینا مالتسوا، اوگنی پانکوف از Rosbank گفتند که چگونه در سه سال به DevOps آمدند. دو هدف وجود داشت: حل مشکلات خاص در تیم های خاص و پیاده سازی ابزارهای متمرکز.

در اینجا نتایج به دست آمده آمده است:

نتایج برای تیم های محصول: مونتاژ 30 برابر سریعتر، نصب 6 برابر سریعتر، تا 30٪ صرفه جویی در چرخه کامل. ما اکنون این توانایی را داریم که یک دکمه را فشار دهیم تا به سمت بهره وری برویم

نتایج برای دستورات پلت فرم: 10 برابر سریعتر مونتاژ و نصب، 87 درصد افزایش تعداد نصب، 46 درصد پوشش تست خودکار. تیم ادغام دیگر یک گلوگاه نیست

بنابراین، چگونه می توان شیوه های DevOps را در یک شرکت خونین پیاده سازی کرد؟

ابتدا یک پروژه آزمایشی را اجرا کنید: تیم ها را انتخاب کنید، تصمیم بگیرید که چگونه معماری را پیاده سازی کنید، و ابزارها را انتخاب کنید. ابزارهایی را با مجوز باز و با نصب در بانک و تخصص در کار با آنها انتخاب کردیم. Rosbank به طور همزمان یک ابر خصوصی را به همراه پلتفرم DevOps مستقر کرد و این در ابتدا کمک کرد. در فضای ابری، دریافت منابع لازم با لمس یک دکمه قبلاً ممکن بود، یک هفته طول بکشد.

در بانک‌ها و سایر شرکت‌ها، لازم است محدودیت‌ها را از قبل با تیم امنیت اطلاعات بررسی کنید و راه‌حلی بیابید که امکان اجرای تغییرات را فراهم کند.

پس از پایلوت، یک راه حل موفق باید افزایش یابد.

1. مهم است که خط لوله را تا حد ممکن "صاف" کنید، پیوندهای غیر ضروری را از آن حذف کنید، ارائه دهندگان ارزش را برجسته کنید، و اجزای باقی مانده را حذف کنید. واسطه ها ضد الگو هستند. به عنوان مثال، در Rosbank، تعدادی از تیم ها توسعه داخلی را توسعه ندادند و تنها توسعه خارجی را باقی گذاشتند. این منجر به ظهور یک تیم اختصاصی DevOps شد که انتقال کد از توسعه دهندگان خارجی به داخلی را تضمین می کرد. مشکل با ادغام توسعه خارجی در CI/CD حل شد تا آنها نه تنها کد را از خودشان به بانک منتقل کنند، بلکه مسئول موفقیت آن نیز باشند.
2. مدل بلوغ شامل عناصری از شیوه‌های DevOps، ابزارهای فهرست‌شده بود و ویژگی‌های کار با تأمین‌کنندگان خارجی را در نظر می‌گرفت - در آینده، این به کاهش سریع کارهای عقب افتاده هنگام اجرای آنها در تیم‌های جدید کمک کرد.
3. ما به حکومتداری در قالب کنترل نرم و توصیه ها نیاز داریم. کتاب راهنمای DevOps که به خوبی کار می کند مجموعه ای از ویژگی های سازمانی و ابزاری است که به تیم ها کمک می کند تا از پلتفرم به درستی استفاده کنند.
4. شما باید فوراً به فرهنگ توجه کنید، در این صورت بسیاری از تغییرات سریعتر و آسان تر رخ خواهند داد. جامعه داخلی خود را رشد دهید، جلسات، کارگاه های فنی، آموزش ها و فعالیت های سرگرم کننده را برگزار کنید. این به ثمر می‌رسد: مردم شیوه‌ها را به اشتراک می‌گذارند، می‌بینند چه کسی چه کاری انجام داده است، می‌دانند به کجا مراجعه کنند، تبلیغات و رقابت سالم در شرکت وجود دارد.
5. کار کردن با کسانی که درگیر این روند نیستند، با تیم هایی که بالغ نشده اند، فایده ای ندارد.
6. راه حل انتخاب شده باید برای آن دسته از مهندسانی که از آن استفاده می کنند مناسب باشد.
7. توسعه خارجی یک مسدود کننده نیست.

کمی سود بیشتر

فهرست کتاب‌هایی که ارزش خواندن برای کسانی که در DevOps هستند، از Alexander Chistyakov، vdsina.ru:

1. ایرینا یاکوتنکو "اراده و خودکنترلی".
2. دانیل کانمن "تفکر، سریع و آهسته".
3. باربارا اوکلی "ذهنی برای اعداد".
4. ماکسیم دوروفف "تکنیک های جدی".
5. ویکتور فرانکل "جستجوی انسان برای معنا".

در ارتباط باشید

ما DevOps را نیز دوست داریم. اطلاعیه های سریال را دنبال کنید @DevOps و @Kubernetes و همچنین سایر رویدادهای Mail.ru Cloud Solutions در کانال تلگرام ما: t.me/k8s_mail

منبع: www.habr.com