DevOps چیست

تعریف DevOps بسیار پیچیده است، بنابراین باید هر بار بحث در مورد آن را از نو شروع کنیم. هزاران نشریه در مورد این موضوع تنها در هابره وجود دارد. اما اگر در حال خواندن این مطلب هستید، احتمالاً می دانید DevOps چیست. چون من نیستم. سلام اسم من هست الکساندر تیتوف (@اسمینوگ) و ما فقط در مورد DevOps صحبت می کنیم و من تجربه خود را به اشتراک می گذارم.

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

زمانی سوار بر امواج ادغام و اکتساب بودم. ابتدا برای یک استارتاپ کوچک به نام Qik کار کردم، سپس توسط یک شرکت کمی بزرگتر به نام اسکایپ خریداری شد، که سپس توسط یک شرکت کمی بزرگتر به نام مایکروسافت خریداری شد. در آن لحظه، شروع به دیدن چگونگی تغییر ایده DevOps در شرکت‌های با اندازه‌های مختلف کردم. پس از آن، من علاقه مند شدم به DevOps از دیدگاه بازار نگاه کنم و من و همکارانم شرکت Express 42 را تأسیس کردیم. اکنون 6 سال است که در امتداد امواج بازار حرکت می کنیم.

از جمله، من یکی از سازمان دهندگان جامعه DevOps Moscow و برگزارکننده DevOps-Days 2017 هستم، اما سال 2018 را سازماندهی نکردم. Express 42 با بسیاری از شرکت ها کار می کند. ما DevOps را در آنجا رشد می‌دهیم، تماشا می‌کنیم که چگونه اتفاق می‌افتد، نتیجه‌گیری می‌کنیم، تجزیه و تحلیل می‌کنیم، نتیجه‌گیری‌هایمان را به همه می‌گوییم، و افراد را در شیوه‌های DevOps آموزش می‌دهیم. در مجموع تمام تلاش خود را می کنیم تا تجربه و تخصص خود را در این زمینه افزایش دهیم.

چرا DevOps

اولین سوالی که همیشه همه را آزار می دهد این است - چرا؟ بسیاری از مردم فکر می کنند که DevOps فقط اتوماسیون یا چیزی مشابه است که هر شرکت قبلاً داشته است.

— ما یکپارچه سازی پیوسته داشتیم - این بدان معناست که ما قبلاً DevOps داشتیم، و چرا همه این موارد مورد نیاز است؟ در خارج از کشور خوش می گذرانند اما ما را از کار باز می دارند!

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

همه اینها به این دلیل است که جهان در حال تغییر است. او از رویکرد سازمانی دور می‌شود، زمانی که شرکت‌ها مستقیماً به سمت یک رویا حرکت می‌کنند، همانطور که کلاسیک سنت پترزبورگ ما می‌خواند، از نقطه A به نقطه B مطابق با یک استراتژی خاص، با ساختار خاصی که برای این کار ساخته شده است.

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

اتوماسیون اغلب تغییر نمی کند، زیرا زمانی که یک شرکت به یک مسیر خوب فرو می رود، چه چیزی برای تغییر وجود دارد؟ کار می کند - به آن دست نزنید. اکنون رویکردها در جهان در حال تغییر هستند و رویکردی به نام Agile نشان می‌دهد که نقطه پایانی B بلافاصله قابل مشاهده نیست.

وقتی یک شرکت از بازار عبور می‌کند، با مشتری کار می‌کند، دائماً بازار را کاوش می‌کند و نقطه پایانی B را تغییر می‌دهد. علاوه بر این، هر چه شرکت بیشتر مسیر خود را تغییر دهد، در نهایت موفق‌تر است، زیرا بازار بیشتری را انتخاب می‌کند. سوله ها

این استراتژی توسط یک شرکت جالب نشان داده شده است که من اخیراً در مورد آن یاد گرفتم. One Box Shave یک سرویس تحویل اشتراک برای ریش تراش ها و لوازم جانبی اصلاح در یک جعبه است. آنها می دانند چگونه "جعبه" خود را برای مشتریان مختلف سفارشی کنند. این کار توسط نرم افزار خاصی انجام می شود و سپس سفارش را به کارخانه کره ای که کالا را تولید می کند ارسال می کند.

این محصول توسط یونیلور به قیمت یک میلیارد دلار خریداری شد. اکنون با ژیلت رقابت می کند و سهم قابل توجهی از مصرف کنندگان در بازار آمریکا را از آن خود کرده است. One Box Shave می گوید:

- 4 تیغه؟ آیا تو جدی هستی؟ چرا به این نیاز دارید - کیفیت اصلاح را بهبود نمی بخشد. یک کرم، عطر و یک تیغ باکیفیت با دو تیغه انتخاب شده، مشکلات بسیار بیشتری را نسبت به آن چهار تیغه احمقانه ژیلت حل می کند! آیا به زودی به 4 می رسیم؟

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

نکته زمان به بازار این نیست که چند وقت یکبار مستقر می شویم. اغلب می توانید مستقر شوید، اما چرخه های انتشار طولانی خواهند بود. اگر چرخه‌های انتشار سه ماهه بر روی یکدیگر قرار بگیرند و یک هفته آنها را تغییر دهند، به نظر می‌رسد که شرکت هفته‌ای یک‌بار استقرار می‌کند. و از ایده تا اجرای نهایی 3 ماه طول می کشد.

زمان به بازار در مورد به حداقل رساندن زمان ایده تا اجرای نهایی است.

در این حالت نرم افزار با بازار در تعامل است. این نحوه تعامل وب سایت One Box Shave با مشتری است. آنها فروشنده ندارند - فقط یک وب سایت که بازدیدکنندگان روی آن کلیک کرده و آرزوها را ترک می کنند. بر این اساس، باید به طور مداوم چیز جدیدی در سایت قرار داده شود و مطابق با خواسته ها به روز شود. به عنوان مثال، در کره جنوبی آنها به روشی متفاوت از روسیه می تراشند و بوی کاج را نه، بلکه مثلاً هویج و وانیل را دوست دارند.

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

به عنوان مثال، در Qik ما ناگهان متوجه شدیم که مردم واقعاً دوست دارند لیست مخاطبین را در سرور آپلود کنند و آنها یک برنامه کاربردی به ما ارائه کردند. در ابتدا به آن فکر نکردیم. در یک شرکت کلاسیک، همه به این نتیجه می‌رسیدند که این یک باگ است، زیرا مشخصات آن نمی‌گفت که باید عالی کار کند و عموماً روی زانو پیاده‌سازی می‌شد، این ویژگی را خاموش می‌کردند و می‌گفتند: «هیچ‌کس به این نیاز ندارد. مهمترین چیز این است که عملکرد اصلی کار می کند. و شرکت فناوری این را یک فرصت می بیند و شروع به تغییر نرم افزار مطابق با این می کند.

در سال 1968، یک مرد رویا به نام ملوین کانوی، ایده زیر را تدوین کرد.

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

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

خواندن در مورد قانون کانوی می توان از طریق پیوندها. برای درک فرهنگ یا فلسفه DevOps مهم است زیرا تنها چیزی که اساساً در DevOps تغییر می کند، ساختار ارتباط بین تیم ها است.

از نقطه نظر فرآیند، قبل از DevOps، تمام مراحل: تجزیه و تحلیل، توسعه، آزمایش، عملیات، خطی بودند.
در مورد DevOps، همه این فرآیندها به طور همزمان انجام می شوند.

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

پس چرا DevOps مورد نیاز است؟

برای توسعه محصول دیجیتال. اگر شرکت شما محصول دیجیتالی ندارد، DevOps مورد نیاز نیست - بسیار مهم است.

DevOps بر محدودیت های سرعت تولید نرم افزار متوالی غلبه می کند. در آن همه فرآیندها به طور همزمان اتفاق می افتد.

سختی افزایش می یابد. هنگامی که مبشر DevOps به شما می گویند که انتشار نرم افزار را برای شما آسان تر می کند، این مزخرف است.

با DevOps، همه چیز پیچیده تر می شود.

در کنفرانسی که در غرفه Avito برگزار شد، می‌توانید ببینید که استقرار یک کانتینر Docker چگونه است - یک کار غیر واقعی. دشواری بسیار زیاد می شود؛ شما باید همزمان با بسیاری از توپ ها دستکاری کنید.

DevOps فرآیند و سازماندهی شرکت را کاملاً تغییر می دهد - به طور دقیق تر، این DevOps نیست که تغییر می کند، بلکه محصول دیجیتال است. برای آمدن به DevOps، هنوز باید این فرآیند را به طور کامل تغییر دهید.

سوالات برای متخصص

چی داری؟ سوالاتی که می توانید هنگام کار در یک شرکت و توسعه به عنوان یک متخصص از خود بپرسید.

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

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

آیا شرکت شما یکی از رهبران بازار در حوزه محصولات دیجیتال است؟ Spotify، Yandex، Uber شرکت هایی هستند که اکنون در اوج پیشرفت تکنولوژی هستند.

این سوالات را از خود بپرسید، و اگر همه پاسخ ها منفی است، شاید نباید در این شرکت DevOps انجام دهید. اگر موضوع DevOps واقعا برای شما جالب است، شاید ... باید به شرکت دیگری بروید؟ اگر شرکت شما می‌خواهد وارد DevOps شود، اما شما به همه سؤالات پاسخ «نه» داده‌اید، آنگاه مانند آن کرگدن زیبا است که هرگز تغییر نخواهد کرد.

سازمان

همانطور که گفتم طبق قانون کانوی، سازمان یک شرکت تغییر می کند. من با چیزی شروع می کنم که از نظر سازمانی مانع از نفوذ DevOps به داخل شرکت می شود.

مشکل "چاه"

کلمه انگلیسی "Silo" در اینجا به روسی به عنوان "خوب" ترجمه شده است. نکته این مشکل این است که تبادل اطلاعات بین تیم ها وجود ندارد. هر تیم بدون ساختن یک نقشه مشترک برای پیمایش، عمیقاً به تخصص خود می پردازد.

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

DevOps پیشنهاد می‌کند که از این لحظه بی‌جهت عبور کنید و همه بخش‌ها با هم کار کنند تا یک نقشه تعامل مشترک ایجاد کنند.

دو عامل مانع این امر می شود.

پیامد سیستم مدیریت شرکت. این در "چاه" سلسله مراتبی جداگانه ساخته شده است. به عنوان مثال، KPI های خاصی در شرکت هایی وجود دارند که از این سیستم پشتیبانی می کنند. از سوی دیگر، مغز افرادی که فراتر از مرزهای تخصص خود و پیمایش در کل سیستم برایشان مشکل است، مانع می شود. این فقط ناراحت کننده است. تصور کنید که در فرودگاه بانکوک هستید - به سرعت راه خود را پیدا نخواهید کرد. پیمایش DevOps نیز دشوار است و به همین دلیل است که مردم می گویند برای رسیدن به آنجا باید یک راهنما پیدا کنید.

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

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

این دقیقاً به این دلیل اتفاق می افتد CI и فرآیند تحویل مداوم در مرز بسیاری از معاینات قرار دارند. به سادگی بدون غلبه بر مشکل "چاه ها" در سطح سازمانی، هر کاری که انجام می دهید و هر چقدر هم که غم انگیز باشد، نمی توانید جلو بروید.

هر یک از شرکت کنندگان در فرآیند در شرکت: توسعه دهندگان باطن و فرانت اند، آزمایش، DBA، عملیات، شبکه، در جهت خود حفاری می کنند و هیچ کس نقشه مشترکی ندارد به جز مدیر، که به نوعی آنها را نظارت می کند و با استفاده از "تقسیم" آنها را مدیریت می کند. و فتح» روش.

مردم برای چند ستاره یا پرچم می جنگند، همه در حال حفاری تخصص خود هستند.

در نتیجه، وقتی وظیفه اتصال همه اینها به یکدیگر و ایجاد یک خط لوله مشترک پیش می‌آید و دیگر نیازی به جنگیدن برای ستاره‌ها و پرچم‌ها نیست، این سؤال پیش می‌آید - به هر حال چه باید کرد؟ ما باید به نوعی به توافق برسیم، اما هیچکس به ما یاد نداد که چگونه این کار را در مدرسه انجام دهیم. از مدرسه به ما یاد داده اند: کلاس هشتم - وای! - نسبت به کلاس هفتم! اینجا هم همینطوره

آیا در شرکت شما هم همینطور است؟

برای بررسی این موضوع می توانید سوالات زیر را از خود بپرسید.

آیا تیم‌ها از ابزارهای رایج استفاده می‌کنند و به تغییرات در آن ابزارهای رایج کمک می‌کنند؟

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

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

دریافت دستاوردهای شخصی بدون در نظر گرفتن دستاوردهای شرکت برای مدیران چقدر اهمیت دارد؟

اگر خودتان به این سوالات پاسخ دهید، مشخص می شود که آیا چنین مشکلی در شرکت خود دارید یا خیر.

زیرساخت به عنوان کد

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

اغلب، زیرساخت به عنوان کد به صورت زیر درک می شود:

- بیایید همه چیز را در bash خودکار کنیم، خودمان را با اسکریپت بپوشانیم تا ادمین ها کار دستی کمتری داشته باشند!

اما این درست نیست.

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

همراه با تیم های دیگر، نقشه ای را به شکل کد ایجاد می کنید که همه بتوانند آن را درک کنند و بتوانند حرکت کنند و پیمایش کنند. فرقی نمی کند روی چه کاری انجام می شود - Chef، Ansible، Salt، یا استفاده از فایل های YAML در Kubernetes - هیچ تفاوتی وجود ندارد.

در کنفرانس، یکی از همکاران 2GIS گفت که چگونه چیز داخلی خود را برای Kubernetes ساخته اند، که ساختار سیستم های فردی را توصیف می کند. برای توصیف 500 سیستم، آنها به ابزار جداگانه ای نیاز داشتند که این توصیف را ایجاد کند. وقتی این توصیف وجود دارد، همه می توانند با یکدیگر بررسی کنند، تغییرات را نظارت کنند، چگونه آن را تغییر دهند و بهبود دهند، چه چیزی از دست رفته است.

موافقم، اسکریپت‌های bash فردی معمولاً این درک را ارائه نمی‌کنند. در یکی از شرکت‌هایی که من در آن کار می‌کردم، حتی نامی برای اسکریپت «فقط نوشتن» وجود داشت - زمانی که فیلمنامه نوشته می‌شود، اما دیگر امکان خواندن آن وجود ندارد. فکر کنم این برای شما هم آشنا باشد.

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

کد بر اساس بهترین شیوه های کد نگهداری می شود: توسعه مشترک، بررسی کد، برنامه نویسی XP، آزمایش، درخواست های کششی، CI برای زیرساخت های کد - همه اینها مناسب هستند و می توان از آنها استفاده کرد.

کد به یک زبان مشترک برای همه مهندسان تبدیل می شود.

تغییر زیرساخت در کد زمان زیادی نمی برد. بله کد زیرساخت می تواند بدهی فنی هم داشته باشد. معمولا تیم‌ها یک سال و نیم بعد از شروع پیاده‌سازی «زیرساخت به‌عنوان کد» در قالب یک سری اسکریپت یا حتی Ansible با آن مواجه می‌شوند که آن‌ها را مانند کد اسپاگتی می‌نویسند و اسکریپت‌های bash را نیز در ترکیب می‌اندازند!

این مهم است: اگر هنوز این موارد را امتحان نکرده اید، آن را به خاطر بسپارید Ansible بش نیست! اسناد را با دقت بخوانید، آنچه را که در مورد آن می نویسند مطالعه کنید.

زیرساخت به عنوان کد، جداسازی کد زیرساخت به لایه های جداگانه است.

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


لایه پایه - اینگونه است که سیستم عامل، پشتیبان گیری و سایر موارد سطح پایین پیکربندی می شوند، به عنوان مثال، نحوه استقرار Kubernetes در سطح پایه.

سطح سرویس - اینها خدماتی هستند که شما به توسعه دهنده ارائه می دهید: ورود به سیستم به عنوان یک سرویس، نظارت به عنوان یک سرویس، پایگاه داده به عنوان یک سرویس، متعادل کننده به عنوان یک سرویس، صف به عنوان یک سرویس، تحویل مداوم به عنوان یک سرویس - مجموعه ای از خدمات که تیم های فردی انجام می دهند. می تواند برای توسعه فراهم کند. همه اینها باید در ماژول های جداگانه در سیستم مدیریت پیکربندی شما توضیح داده شود.

لایه ای که برنامه ها در آن ساخته می شوند و نحوه باز شدن آنها در بالای دو لایه قبلی را توضیح می دهد.

کنترل سوالات

آیا شرکت شما یک مخزن زیرساخت مشترک دارد؟ آیا بدهی فنی را در زیرساخت خود مدیریت می کنید؟ آیا از شیوه های توسعه در مخزن زیرساخت استفاده می کنید؟ آیا زیرساخت شما به لایه ها تقسیم شده است؟ می توانید نمودار Base-service-APP را بررسی کنید. چقدر ایجاد تغییر سخت است؟

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

تحویل مستمر

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

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

وقتی با هم هستیم وانیا اوتوخوویچ اولین کتاب را دیدم جز فروتن و گروه های نویسندگان "تحویل مستمر"، که در سال 2009 منتشر شد، مدت زیادی فکر کردیم که چگونه عنوان آن را به روسی ترجمه کنیم. آنها می خواستند آن را به عنوان "تحویل مداوم" ترجمه کنند، اما متأسفانه به عنوان "تحویل مداوم" ترجمه شد. به نظر من چیزی روسی به نام ما وجود دارد، با فشار.

به طور مداوم تحویل ابزار

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

برای ارائه مداوم، به یک قالب مصنوع نیاز دارید که در یک پلت فرم زیرساخت اجرا شود. اگر «اتلاف عمر» را با فرمت‌های مختلف روی یک پلتفرم زیرساخت پرتاب کنید، آنگاه یکپارچه می‌شود، نگهداری آن دشوار است و مشکل بدهی فنی به وجود می‌آید. قالب مصنوع باید هماهنگ شود - این نیز یک وظیفه جمعی است: همه ما باید دور هم جمع شویم، مغزمان را خش خش کنیم و به این قالب برسیم.

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

این تا حدودی یادآور بازی Pac-Man است - این مصنوع از طریق نوعی داستان می گذرد. در عین حال، مهم است که کنترل کنید آیا کد واقعاً از طریق داستان عبور می کند و آیا به نوعی با تولید شما مرتبط است یا خیر. داستان‌های تولید را می‌توان به فرآیند تحویل مداوم کشاند: زمانی که چیزی سقوط می‌کرد به این صورت بود، حالا اجازه دهید این سناریو را در داخل سیستم برنامه‌ریزی کنیم. هر بار کد از این سناریو نیز عبور می کند و دفعه بعد با این مشکل مواجه نخواهید شد. شما خیلی زودتر از آن که به دست مشتری شما برسد در مورد آن مطلع خواهید شد.

استراتژی های مختلف استقرار به عنوان مثال، شما از تست AB یا استقرار قناری برای آزمایش متفاوت کد روی کلاینت‌های مختلف، دریافت اطلاعات در مورد نحوه کارکرد کد و خیلی زودتر از زمانی که برای 100 میلیون کاربر عرضه می‌شود، استفاده می‌کنید.

"به طور مداوم تحویل دهید" به این شکل است.

فرآیند تحویل Dev, CI, Test, PreProd, Prod یک محیط جداگانه نیست، اینها مراحل یا ایستگاه هایی با مبالغ نسوز هستند که مصنوع شما از آن عبور می کند.

اگر کد زیرساختی دارید که به عنوان Base Service APP توصیف شده است، به شما کمک می کند همه فیلمنامه ها را فراموش نکنیدو آنها را به عنوان کد این مصنوع یادداشت کنید، مصنوع را ترویج کنید و در حین رفتن آن را تغییر دهید.

سوالات خودآزمایی

زمان از شرح ویژگی تا عرضه به تولید در 95٪ موارد کمتر از یک هفته است؟ آیا کیفیت مصنوع در هر مرحله از خط لوله بهبود می یابد؟ آیا داستانی وجود دارد که از آن عبور کند؟ آیا از استراتژی های مختلف استقرار استفاده می کنید؟

اگر همه پاسخ ها مثبت است، پس شما فوق العاده باحال هستید! پاسخ های خود را در نظرات بنویسید - خوشحال خواهم شد).

باز خورد

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

به عنوان مثال، خیلی وقت پیش، زمانی که من در کیک کار می کردم و متوجه شدیم که باید همه چیز را زیر نظر داشته باشیم. ما این کار را انجام دادیم و در حال حاضر 150 مورد در Zabbix داریم که دائماً تحت نظارت هستند. ترسناک بود، مدیر فنی انگشتش را روی شقیقه‌اش چرخاند:

- بچه ها چرا با یه چیز نامشخص به سرور تجاوز می کنید؟

اما پس از آن حادثه ای رخ داد که نشان داد این واقعاً یک استراتژی بسیار جالب است.

یکی از سرویس ها دائما شروع به خراب شدن کرد. در ابتدا، خراب نشد، که جالب است، کد در آنجا اضافه نشد، زیرا یک کارگزار اولیه بود که عملاً هیچ عملکرد تجاری نداشت - فقط پیام هایی را بین خدمات فردی ارسال می کرد. سرویس به مدت 4 ماه تغییر نکرد و ناگهان با خطای "Segmentation fault" شروع به خراب شدن کرد.

ما شوکه شدیم، نمودارهای خود را در Zabbix باز کردیم، و معلوم شد که یک هفته و نیم پیش، رفتار درخواست ها در سرویس API که این بروکر از آن استفاده می کند، بسیار تغییر کرده است. بعد دیدیم که فرکانس ارسال نوع خاصی از پیام تغییر کرده است. بعداً متوجه شدیم که اینها مشتریان اندرویدی هستند. ما پرسیدیم:

- بچه ها، یک هفته و نیم پیش چه اتفاقی برای شما افتاد؟

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

بدون نظارت عمیق به طور کلی باز کردن این غیرممکن است. اگر سازمان هنوز مشکل «چاه» را داشته باشد، وقتی همه به همدیگر پول پرتاب می کنند، این می تواند سال ها ادامه یابد. شما به سادگی سرور را راه اندازی مجدد می کنید زیرا حل مشکل غیرممکن است. وقتی همه رویدادهایی را که دارید نظارت می کنید، ردیابی می کنید، ردیابی می کنید، و از نظارت به عنوان آزمایش استفاده می کنید - کد بنویسید و بلافاصله نحوه نظارت بر آن را نشان دهید، همچنین به صورت کد (ما قبلا زیرساخت را به عنوان کد داریم)، ​​همه چیز مشخص می شود که چگونه روی کف دست حتی چنین مشکلات پیچیده ای به راحتی قابل پیگیری است.

جمع آوری تمام اطلاعات در مورد آنچه برای مصنوع در هر مرحله از فرآیند تحویل - نه در تولید اتفاق می افتد.

مانیتورینگ را در CI آپلود کنید، و برخی از چیزهای اساسی از قبل در آنجا قابل مشاهده خواهند بود. بعداً آنها را در تست، PredProd و بارگذاری خواهید دید. جمع آوری اطلاعات در تمام مراحل، نه تنها معیارها، آمار، بلکه سیاهههای مربوط: نحوه انتشار برنامه، ناهنجاری ها - همه چیز را جمع آوری کنید.

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

سوالاتی برای خودکنترلی

آیا نظارت و ثبت گزارش شما ابزار توسعه برای شماست؟ آیا هنگام نوشتن کد، توسعه دهندگان شما، از جمله شما، به نحوه نظارت بر آن فکر می کنند؟

آیا در مورد مشکلات از مشتریان می شنوید؟ آیا مشتری را از نظارت و ثبت اطلاعات بهتر درک می کنید؟ آیا سیستم را از مانیتورینگ و لاگ بهتر درک می کنید؟ آیا شما فقط به این دلیل که دیدید روند در سیستم رو به رشد است و می فهمید که تا 3 هفته دیگر همه چیز از بین می رود، سیستم را تغییر می دهید؟

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

پلت فرم زیرساخت

نکته این نیست که این مجموعه ابزارهای متفاوتی است که هر شرکتی دارد.

نکته یک پلتفرم زیرساخت این است که همه تیم ها از این ابزارها استفاده کرده و آنها را با هم توسعه می دهند.

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

همه تیم ها پلتفرم زیرساخت را توسعه می دهند و با احتیاط به عنوان IDE خود رفتار می کنند. در IDE خود پلاگین های مختلفی را نصب می کنید تا همه چیز خوب و سریع باشد و کلیدهای میانبر را پیکربندی کنید. وقتی Sublime، Atom یا Visual Studio Code را باز می‌کنید، خطاهای کد سرازیر می‌شوند و متوجه می‌شوید که کار کردن اصلاً غیرممکن است، بلافاصله غمگین می‌شوید و می‌روید تا IDE خود را اصلاح کنید.

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

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

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

طرح

این یک نمودار اساسی از یک پلتفرم زیرساختی است که به شما کمک می کند تا تمام اقدامات و فرآیندها را در یک شرکت DevOps تنظیم کنید.

بیایید ببینیم از چه چیزی تشکیل شده است.

سیستم ارکستراسیون منابع، که CPU، حافظه، دیسک را به برنامه ها و سایر خدمات ارائه می دهد. در بالای این - خدمات سطح پایین: نظارت، ورود به سیستم، موتور CI/CD، ذخیره سازی مصنوعات، زیرساخت به عنوان کد سیستم.

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

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

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

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

ایجاد پلت فرم

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

با فرهنگ همه چیز بسیار ساده است - این در مورد همکاری و ارتباطات است، یعنی میل به کار در یک زمینه مشترک با یکدیگر، میل به استفاده از یک ساز با هم. در اینجا هیچ علم موشکی وجود ندارد - همه چیز بسیار ساده و پیش پا افتاده است. به عنوان مثال، همه ما در ورودی زندگی می کنیم و آن را تمیز نگه می داریم - چنین سطحی از فرهنگ.

چی داری؟

باز هم سوالاتی که می توانید از خود بپرسید.

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

باید این سوالات را مدام از خود بپرسید. اگر چیزی می تواند به سرویس های شخص ثالث منتقل شود، باید منتقل شود؛ اگر یک سرویس شخص ثالث شروع به مسدود کردن حرکت شما کرد، باید یک سیستم در درون خود بسازید.

بنابراین، DevOps...

... این یک سیستم پیچیده است، باید دارای:

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

می توانید از این نمودار استفاده کنید و آنچه را که قبلاً در شرکت خود دارید به شکلی در آن برجسته کنید: آیا توسعه یافته است یا هنوز باید توسعه یابد.

یکی دو هفته دیگه تموم میشه DevOpsConf 2019. به عنوان بخشی از RIT++. به کنفرانس بیایید، جایی که گزارش های جالب زیادی در مورد تحویل مداوم، زیرساخت به عنوان کد و تحول DevOps خواهید دید. بلیط های خود را رزرو کنیدآخرین مهلت قیمت 20 اردیبهشت می باشد

منبع: www.habr.com