DevOps کیست و چه زمانی نیازی به آن نیست

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

برخی از آنها DevOps را در رزومه خود نشان می دهند، اگرچه آنها همیشه ماهیت این اصطلاح را نمی دانند و درک نمی کنند. کسی فکر می کند که با مطالعه Ansible، GitLab، Jenkins، Terraform و موارد مشابه (لیست را می توان به سلیقه شما ادامه داد)، بلافاصله تبدیل به یک "devops" می شود. این البته درست نیست.

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

DevOps کیست

ایده نوشتن مقاله پس از سوال دیگری مطرح شد: "DevOps کیست؟". هنوز هیچ اصطلاح مشخصی برای چیست یا چه کسی وجود ندارد. برخی از پاسخ ها در حال حاضر در این است تصویری. ابتدا تزهای اصلی را از آن برجسته می کنم و سپس مشاهدات و افکار خود را به اشتراک می گذارم.

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

DevOps یک فلسفه و روش است.

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

با ظهور DevOps، ساختار و نقش متخصصان ثابت مانده است (توسعه دهندگان هستند، مهندسان هستند)، اما قوانین تعامل تغییر کرده است. مرزهای بین بخش ها محو شده است.

اهداف DevOps را می توان در سه نکته خلاصه کرد:

• نرم افزار باید به طور مرتب به روز شود.
• نرم افزار باید سریع ساخته شود.
• نرم افزار باید به راحتی و در زمان کوتاهی مستقر شود.

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

و این تنها بخشی از ابزار DevOps است

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

از تجربه مصاحبه ها این تصویر را می بینم: متخصصانی که DevOps را یک موقعیت می دانند معمولاً با همکاران خود سوءتفاهم دارند.

یک مثال برجسته وجود داشت. مرد جوانی با انبوهی از کلمات کلیدی در رزومه خود به مصاحبه آمد. در سه محل کار آخر 5-6 ماه تجربه داشت. او دو استارت‌آپ را ترک کرد زیرا آنها «بلند نشدند». اما در مورد شرکت سوم ، او گفت که هیچ کس او را در آنجا درک نمی کند: توسعه دهندگان کد را برای ویندوز می نویسند و کارگردان این کد را در Docker معمولی "پیچیده" می کند و در خط لوله CI / CD جاسازی می کند. آن مرد در مورد محل کار فعلی و همکارانش چیزهای منفی زیادی گفت - من فقط می خواستم پاسخ دهم: "پس شما یک فیل را نمی فروشید."

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

DevOps شخصاً برای شما چه معنایی دارد؟
- به طور کلی، یا چگونه آن را درک کنم؟

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

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

روش شناسی و فلسفه DevOps

روش شناسی نظری و عملی است. در مورد ما، مورد دوم. همانطور که در بالا ذکر کردم، DevOps مجموعه ای از شیوه ها و استراتژی هایی است که برای دستیابی به اهداف تعیین شده استفاده می شود. و در هر مورد، بسته به فرآیندهای تجاری شرکت، می تواند تفاوت قابل توجهی داشته باشد. این وضعیت را بهتر یا بدتر نمی کند.

متدولوژی DevOps فقط وسیله ای برای دستیابی به اهداف شماست.

حالا در مورد فلسفه DevOps چیست. و این شاید سخت ترین سوال باشد.

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

در دانشگاه من چنین موضوعی وجود نداشت، من مجبور بودم همه چیز را به تنهایی با استفاده از موادی که در دهه 90 پیدا می کردم مطالعه کنم. مبحث برای آموزش مهندسی اختیاری است، از این رو عدم رسمیت یافتن پاسخ. اما آن دسته از افرادی که به طور جدی در DevOps غوطه ور هستند، شروع به احساس یک «روح» یا «جامع ناخودآگاه» در تمام فرآیندهای شرکت می کنند.

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

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

من فکر می کنم که "مقامات" من یک موضوع جداگانه برای بحث است. اما اکنون چیزی برای ساختن وجود دارد.

DevOps چه می کند؟

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

من نمی توانم با اطمینان 100% در مورد بازار کار غرب صحبت کنم. اما من اطلاعات زیادی در مورد بازار DevOps در روسیه دارم. علاوه بر صدها مصاحبه، طی یک سال و نیم گذشته در صدها پیش فروش فنی در سرویس پیاده سازی DevOps برای شرکت ها و بانک های بزرگ روسی شرکت کرده ام.

در روسیه، DevOps هنوز بسیار جوان است، اما در حال حاضر یک موضوع پرطرفدار است. تا آنجا که من می دانم، تنها در مسکو، کمبود چنین متخصصانی در سال 2019 به بیش از 1000 نفر رسید. و کلمه Kubernetes برای کارفرمایان تقریباً مانند پارچه قرمز برای یک گاو نر است. طرفداران این ابزار حتی در جاهایی که نیازی به آن نیست و از نظر اقتصادی به صرفه نیست، آماده استفاده از آن هستند. کارفرما همیشه نمی‌داند در چه مواردی چه چیزی مناسب‌تر است، و با استقرار مناسب، هزینه نگهداری یک خوشه Kubernetes 2-3 برابر بیشتر از استقرار یک برنامه کاربردی با استفاده از یک طرح کلاستر معمولی است. در جایی که واقعا به آن نیاز دارید استفاده کنید.

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

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

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

یک توسعه دهنده فقط باید کد بنویسد و آزمایش کند. برای انجام این کار، او نیازی به یک لپ تاپ فوق العاده قدرتمند ندارد که تمام زیرساخت های پروژه را به صورت محلی روی آن مستقر کرده و نگهداری کند. به عنوان مثال، front-ender تمام عناصر برنامه را روی لپ تاپ خود نگه می دارد، از جمله پایگاه داده، شبیه ساز S3 (minio) و غیره. یعنی زمان زیادی را صرف حفظ این زیرساخت های محلی می کند و به تنهایی با تمام مشکلات چنین راه حلی دست و پنجه نرم می کند. به جای توسعه کد برای جلو. چنین افرادی می توانند به شدت در برابر هر تغییری مقاومت کنند.

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

وقتی DevOps مورد نیاز نیست

شرایطی وجود دارد که به DevOps نیازی نیست. این یک واقعیت است - باید آن را درک کرد و پذیرفت.

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

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

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

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

• DevOops
• DevOpsConf
• HighLoad++
• فلانت
• MailRu Cloud Solution

اکنون به کسب و کار خود نگاه کنید و به این فکر کنید: شرکت شما و سود آن چقدر به محصولات فناوری اطلاعات برای ارائه تجربه مشتری بستگی دارد؟

اگر شرکت شما ماهی را در یک فروشگاه کوچک می فروشد و تنها محصول فناوری اطلاعات دو پیکربندی 1C است: Enterprise (حسابداری و UNF)، پس منطقی نیست که در مورد DevOps صحبت کنید.

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

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

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

مشتریان آنها لیست محدودی از فروشندگان خودرو هستند. و یک متخصص از سازنده به هر یک متصل است. تمام جریان اسناد داخلی از طریق SAP ERP انجام می شود. کارکنان داخلی در واقع مشتریان سیستم اطلاعاتی هستند. اما مدیریت این IS با ابزارهای کلاسیک مدیریت سیستم های خوشه ای انجام می شود. که امکان استفاده از شیوه های DevOps را حذف می کند.

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

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

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

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

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

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

اکنون ما به طور فعال از Jenkins به عنوان یک ابزار خط لوله CI / CD برای انجام تمام خطوط لوله مونتاژ با Unity و استقرار بعدی در فروشگاه App و Play Market استفاده می کنیم. اطلاعات بیشتر از مجموعه ابزارهای کلاسیک:

• آسانا - برای مدیریت پروژه. ادغام را با جنکینز تنظیم کنید.
• Google Meet - برای جلسات ویدیویی.
• Slack - برای ارتباطات و اعلان‌های مختلف، از جمله اعلان‌های Jenkins.
• Atlassian Confluence - برای مستندسازی و کار گروهی.

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

به جای یک نتیجه گیری

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

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

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

منبع: www.habr.com