برای موفقیت یک شرکت فناوری اطلاعات در سال 2019 چه چیزی لازم است؟ سخنرانان در کنفرانس ها و جلسات، کلمات بلند زیادی می گویند که همیشه برای مردم عادی قابل درک نیست. مبارزه برای زمان استقرار، میکروسرویس ها، کنار گذاشتن یکپارچه، تحول DevOps و بسیاری موارد دیگر. اگر زیبایی کلامی را کنار بگذاریم و مستقیماً و به زبان روسی صحبت کنیم، همه چیز به یک پایان نامه ساده ختم می شود: محصولی با کیفیت بالا بسازیم و آن را با خیال راحت برای تیم انجام دهیم.
دومی به شدت مهم شده است. کسب و کار در نهایت به این نتیجه رسیده است که یک فرآیند توسعه راحت بهره وری را افزایش می دهد و اگر همه چیز اشکال زدایی شود و مانند یک ساعت کار کند، در شرایط بحرانی نیز فضایی برای مانور می دهد. روزی روزگاری به خاطر این مانور، یک فرد باهوش خاص پشتیبان تهیه کرد، اما صنعت در حال توسعه است، و ما به مهندسان DevOps رسیدیم - افرادی که فرآیند تعامل بین توسعه و زیرساخت های خارجی را به چیزی مناسب و کافی تبدیل می کنند. ربطی به شمنیسم ندارد.
کل این داستان «مژولار» فوق‌العاده است، اما... این اتفاق افتاد که برخی از ادمین‌ها به طور ناگهانی DevOps لقب گرفتند و خود مهندسان DevOps شروع کردند به داشتن حداقل مهارت‌های تله پاتی و روشن بینی.
قبل از اینکه در مورد مشکلات مدرن تامین زیرساخت صحبت کنیم، بیایید منظورمان از این اصطلاح را تعریف کنیم. در حال حاضر شرایط به گونه‌ای پیش رفته است که به دوگانگی این مفهوم رسیده‌ایم: زیرساخت می‌تواند مشروط خارجی و مشروط داخلی باشد.
منظور ما از زیرساخت خارجی هر چیزی است که عملکرد سرویس یا محصولی را که تیم در حال توسعه است تضمین می کند. اینها سرورهای برنامه یا وب سایت، هاست و سایر خدماتی هستند که عملکرد محصول را تضمین می کنند.
زیرساخت داخلی شامل خدمات و تجهیزاتی است که توسط خود تیم توسعه و سایر کارکنان که معمولا تعداد زیادی از آنها وجود دارد، استفاده می شود. اینها سرورهای داخلی سیستم‌های ذخیره‌سازی کد، یک مدیر وظیفه محلی مستقر شده و همه چیز، همه چیز، همه چیزهایی هستند که در اینترانت شرکت وجود دارد.
مدیر سیستم در یک شرکت چه می کند؟ علاوه بر کار مدیریت این اینترانت بسیار شرکتی، اغلب بار نگرانی های اقتصادی برای اطمینان از عملکرد تجهیزات اداری را به دوش می کشد. ادمین همان کسی است که به سرعت یک واحد سیستم جدید یا یک لپ‌تاپ یدکی آماده برای استفاده را از اتاق پشتی می‌کشد، یک صفحه‌کلید تازه می‌دهد و چهار دست و پا در دفاتر می‌خزد و کابل اترنت را دراز می‌کند. مدیر یک مالک محلی و حاکم نه تنها سرورهای داخلی و خارجی، بلکه یک مدیر تجاری است. بله، برخی از مدیران فقط می توانند در صفحه سیستم، بدون سخت افزار کار کنند. آنها باید به یک زیر کلاس جداگانه از "مدیران سیستم زیرساخت" تفکیک شوند. و برخی در خدمات انحصاری تجهیزات اداری تخصص دارند؛ خوشبختانه اگر شرکت بیش از صد نفر داشته باشد، کار هرگز تمام نمی شود. اما هیچکدام از آنها توسعه دهنده نیستند.
DevOps چه کسانی هستند؟ Devops افرادی هستند که در مورد تعامل توسعه نرم افزار با زیرساخت خارجی صحبت می کنند. به‌طور دقیق‌تر، توسعه‌دهندگان مدرن در فرآیندهای توسعه و استقرار بسیار عمیق‌تر از ادمین‌هایی که به‌سادگی به‌روزرسانی‌ها را در ftp آپلود می‌کنند، درگیر هستند. یکی از وظایف کلیدی یک مهندس DevOps در حال حاضر اطمینان از یک فرآیند راحت و ساختار یافته تعامل بین تیم های توسعه و زیرساخت محصول است. این افراد هستند که مسئول استقرار سیستم‌های بازگشت و استقرار هستند؛ این افراد هستند که بخشی از بار را از دوش توسعه‌دهندگان برمی‌دارند و تا آنجا که ممکن است روی وظیفه بسیار مهم خود تمرکز می‌کنند. در عین حال، devops هرگز کابل جدیدی را اجرا نمی کند یا لپ تاپ جدیدی را از اتاق پشتی (c) KO صادر نمی کند.
گرفتاری چیست؟
در پاسخ به این سوال که DevOps کیست؟ نیمی از کارگران در این زمینه شروع به پاسخ دادن به چیزی مانند "خب، به طور خلاصه، این مدیر است که ..." و بیشتر در متن. بله، روزی روزگاری، زمانی که حرفه مهندس DevOps به تازگی از بین با استعدادترین مدیران از نظر نگهداری خدمات ظهور می کرد، تفاوت بین آنها برای همه آشکار نبود. اما اکنون که کارکردهای devops و admin در تیم کاملاً متفاوت شده است، اشتباه گرفتن آنها با یکدیگر یا حتی یکسان سازی آنها غیرقابل قبول است.
اما این برای تجارت چه معنایی دارد؟
استخدام، همه چیز در مورد آن است.
شما یک جای خالی برای "System Administrator" باز می کنید و الزامات ذکر شده در آنجا عبارتند از "تعامل با توسعه و مشتریان"، "سیستم تحویل CI/CD"، "نگهداری از سرورها و تجهیزات شرکت"، "اداره سیستم های داخلی" و غیره بر؛ می فهمی که کارفرما مزخرف می گوید. نکته این است که به جای "System Administrator" عنوان جای خالی باید "DevOps Engineer" باشد و اگر این عنوان تغییر کند، همه چیز سر جای خود قرار می گیرد.
با این حال، چه برداشتی از خواندن چنین جای خالی می شود؟ این که این شرکت به دنبال یک اپراتور چند ماشینی است که هم سیستم کنترل نسخه و هم سیستم مانیتورینگ را مستقر کند و پیچش را با دندان هایش فشار دهد ...
اما برای اینکه درجه اعتیاد به مواد مخدر در بازار کار افزایش پیدا نکند، کافی است مشاغل خالی را با نام خاص خود صدا بزنید و به وضوح درک کنید که یک مهندس DevOps و یک مدیر سیستم دو نهاد متفاوت هستند. اما تمایل سرکوب‌ناپذیر برخی از کارفرمایان برای ارائه گسترده‌ترین فهرست ممکن از الزامات به یک نامزد منجر به این واقعیت می‌شود که مدیران سیستم "کلاسیک" از درک آنچه در اطراف آنها می‌گذرد، دست می‌کشند. چه، این حرفه در حال جهش است و آنها عقب مانده اند؟
نه نه و یک بار دیگر نه مدیران زیرساختی که سرورهای داخلی شرکت را مدیریت می‌کنند، یا موقعیت‌های پشتیبانی L2/L3 را اشغال می‌کنند و به سایر کارمندان کمک می‌کنند، کنار نرفته‌اند و قرار هم نیستند.
آیا این متخصصان می توانند مهندس DevOps شوند؟ البته می توانند. در واقع، این یک محیط مرتبط است که نیاز به مهارت های مدیریت سیستم دارد، اما علاوه بر این، کار با نظارت، سیستم های تحویل و به طور کلی تعامل نزدیک با تیم توسعه و تست اضافه می شود.
یکی دیگر از مشکلات DevOps
در واقع، همه چیز فقط به استخدام و سردرگمی مداوم بین ادمین ها و توسعه دهندگان محدود نمی شود. در مقطعی، کسب و کار با مشکل ارائه به روز رسانی و تعامل تیم توسعه با زیرساخت نهایی مواجه شد.
شاید زمانی بود که عمویی با چشمانی درخشان روی صحنه کنفرانسی ایستاد و گفت: «ما این کار را انجام می‌دهیم و آن را DevOps می‌نامیم. این بچه ها همه مشکلات شما را حل خواهند کرد" - و شروع به گفتن کرد که زندگی در شرکت پس از اجرای روش های DevOps چقدر خوب است.
با این حال، استخدام یک مهندس DevOps برای اینکه همه چیز آنطور که باید کار کند، کافی نیست. این شرکت باید تحت یک تحول کامل DevOps قرار گیرد، یعنی نقش و قابلیت‌های DevOps ما نیز باید در کنار تیم توسعه و آزمایش محصول به وضوح درک شود. ما یک داستان "شگفت انگیز" در مورد این موضوع داریم که به طور کامل تمام بی رحمی هایی را که در برخی مکان ها اتفاق می افتد نشان می دهد.
وضعیت. DevOps برای استقرار یک سیستم بازگشت نسخه بدون کاوش در مورد نحوه عملکرد آن الزامی است. بیایید فرض کنیم که در سیستم کاربران فیلدهای جداگانه برای نام، نام خانوادگی و رمز عبور وجود دارد. نسخه جدیدی از محصول منتشر می شود، اما برای توسعه دهندگان، "بازگشت" فقط یک عصای جادویی است که همه چیز را درست می کند، و آنها حتی نمی دانند چگونه کار می کند. بنابراین، به عنوان مثال، در پچ بعدی، توسعه دهندگان فیلدهای نام و نام خانوادگی را با هم ترکیب کردند، آن را به تولید رساندند، اما نسخه به دلایلی کند است. چه اتفاقی می افتد؟ مدیریت به devop می‌آید و می‌گوید «سوئیچ را بکش!»، یعنی از او می‌خواهد به نسخه قبلی برگردد. devops چه می کند؟ به نسخه قبلی برمی‌گردد، اما از آنجایی که توسعه‌دهندگان نمی‌خواستند بفهمند این بازگشت چگونه انجام می‌شود، هیچ‌کس به تیم devops نگفت که پایگاه داده نیز باید بازگردانده شود. در نتیجه همه چیز برای ما خراب می شود و به جای وب سایت کند، کاربران خطای 500 را مشاهده می کنند، زیرا نسخه قدیمی با فیلدهای پایگاه داده جدید کار نمی کند. Devops از این موضوع اطلاعی ندارد. توسعه دهندگان ساکت هستند. مدیریت شروع به از دست دادن اعصاب و پول خود می کند و نسخه های پشتیبان را به خاطر می آورد و پیشنهاد می دهد از آنها عقب نشینی کند تا "حداقل چیزی کار کند". در نتیجه، کاربران تمام اطلاعات خود را در یک دوره زمانی از دست می دهند.
مطمئناً به devops می‌رسد که «سیستم بازگشت مناسبی ایجاد نکرده است» و هیچ‌کس اهمیتی نمی‌دهد که گوزن‌های این داستان توسعه‌دهنده باشند.
نتیجه گیری ساده است: بدون یک رویکرد عادی به DevOps به این ترتیب، کاربرد کمی دارد.
نکته اصلی که باید به خاطر بسپارید: یک مهندس DevOps یک شعبده باز نیست و بدون ارتباطات با کیفیت و تعامل دو طرفه با توسعه، با وظایف خود کنار نخواهد آمد. توسعه دهندگان را نمی توان با «مشکلات» خود تنها گذاشت یا دستور «با توسعه دهندگان مداخله نکنید، وظیفه آنها کدنویسی است» داده شود و سپس امیدوار باشید که در یک لحظه حساس همه چیز همانطور که باید کار کند. اینطوری کار نمی کند.
در اصل، DevOps یک شایستگی در مرز بین مدیریت و فناوری است. علاوه بر این، بدیهی نیست که در این کوکتل فناوری بیشتری نسبت به مدیریت وجود داشته باشد. اگر واقعاً می‌خواهید فرآیندهای توسعه سریع‌تر و کارآمدتری ایجاد کنید، باید به تیم devops خود اعتماد کنید. او ابزارهای مناسب را می شناسد، پروژه های مشابهی را اجرا کرده است، می داند چگونه این کار را انجام دهد. به او کمک کنید، به توصیه های او گوش دهید، سعی نکنید او را در نوعی واحد خودمختار منزوی کنید. اگر ادمین ها بتوانند به تنهایی کار کنند، پس devops در این مورد بی فایده هستند؛ اگر خودتان نخواهید این کمک را قبول کنید، نمی توانند به شما کمک کنند تا بهتر شوید.
و آخرین نکته: توهین به مدیران زیرساخت را متوقف کنید. آنها جبهه کاری بسیار مهم خود را دارند. بله، یک مدیر می تواند یک مهندس DevOps شود، اما این باید به درخواست خود شخص اتفاق بیفتد، نه تحت فشار. و هیچ اشکالی در این واقعیت وجود ندارد که یک مدیر سیستم می خواهد یک مدیر سیستم باقی بماند - این حرفه جداگانه و حق او است. اگر می‌خواهید دچار تحول حرفه‌ای شوید، هرگز نباید فراموش کنید که نه تنها باید مهارت‌های فنی، بلکه مهارت‌های مدیریتی را نیز ایجاد کنید. به احتمال زیاد، این به شما به عنوان یک رهبر بستگی دارد که همه این افراد را دور هم جمع کنید و به آنها بیاموزید که به یک زبان ارتباط برقرار کنند.
منبع: www.habr.com