چرا مدیران سیستم باید مهندس DevOps شوند؟

چرا مدیران سیستم باید مهندس DevOps شوند؟

هیچ زمانی بهتر از امروز برای یادگیری در زندگی وجود ندارد.


سال 2019 است و DevOps بیشتر از همیشه مرتبط است. می گویند دوران مدیران سیستم به پایان رسیده است، درست مثل دوران مین فریم. اما آیا واقعا اینطور است؟
همانطور که اغلب در IT اتفاق می افتد، وضعیت تغییر کرده است. متدولوژی DevOps پدیدار شده است، اما بدون فردی با مهارت های مدیر سیستم، یعنی بدون Ops، نمی تواند وجود داشته باشد.

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

چرا مدیران سیستم باید مهندس DevOps شوند؟

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

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

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

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

اول از همه، درک این نکته مهم است که DevOps یک موقعیت خاص در یک شرکت نیست، بلکه مجموعه ای از اقدامات خاص است. این شیوه‌ها شامل توزیع سیستم‌های ایزوله، کاهش آسیب‌های ناشی از باگ‌ها و خطاها، به‌روزرسانی‌های مکرر و به موقع نرم‌افزار، تعامل خوب بین توسعه‌دهندگان (Dev) و مدیران (Ops) و همچنین آزمایش مداوم نه تنها کد، بلکه همچنین کل ساختار در فرآیند ادغام و تحویل مداوم (CI/CD).

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

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

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

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

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

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

اما این گفته چقدر درست است؟

مدیر سیستم: یک جنگجو در میدان

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

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

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

او همچنین مسئول ارتقاء سخت افزار، بازرسی و تجزیه و تحلیل گزارش، ممیزی های امنیتی، وصله سرور، عیب یابی، تجزیه و تحلیل علت ریشه و اتوماسیون خواهد بود – معمولاً از طریق اسکریپت های PowerShell، Python یا Bash. یک نمونه استفاده سناریوها مدیریت حساب های کاربری و گروهی است. ایجاد حساب های کاربری و تخصیص مجوزها یک کار بسیار خسته کننده است زیرا کاربران تقریباً هر روز ظاهر می شوند و ناپدید می شوند. اتوماسیون از طریق اسکریپت ها زمان را برای وظایف زیرساختی مهم تر، مانند ارتقاء سوئیچ ها و سرورها و سایر پروژه هایی که بر سودآوری شرکتی که مدیر در آن کار می کند، آزاد می کند (حتی اگر به طور کلی پذیرفته شده است که بخش فناوری اطلاعات به طور مستقیم درآمد ایجاد نمی کند).

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

با گذشت زمان، مدیران سیستم یاد گرفته اند که استراتژیک فکر کنند و امور مهم را با وظایف معمول ترکیب کنند. تیم‌ها و بخش‌هایی که در آن‌ها کار می‌کنند معمولاً منابع کمی دارند، اما در عین حال همه تلاش می‌کنند تا وظایف روزانه را به حداکثر برسانند.

DevOps: توسعه و نگهداری به عنوان یک

DevOps نوعی فلسفه برای فرآیندهای توسعه و نگهداری است. این رویکرد در دنیای فناوری اطلاعات واقعاً نوآورانه شده است.

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

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

اگر مدیران سیستم می‌خواهند جدیدترین فن‌آوری‌ها را بیاموزند و پذیرای ایده‌ها و راه‌حل‌های نوآورانه باشند، می‌توانند وارد یک تیم DevOps شوند. همانطور که قبلاً گفتم، آنها مجبور نیستند برنامه نویسان تمام عیار شوند، اما تسلط بر زبان برنامه نویسی مانند Ruby، Python یا Go به آنها کمک می کند تا اعضای بسیار مفیدی در تیم شوند. اگرچه مدیران سیستم به طور سنتی همه کارها را خودشان انجام می دهند و اغلب به عنوان افراد تنها تلقی می شوند، در DevOps آنها یک تجربه کاملاً متضاد دارند، که در آن همه افراد در این فرآیند با یکدیگر تعامل دارند.

موضوع اتوماسیون به طور فزاینده ای مرتبط می شود. هم مدیران سیستم و هم متخصصان DevOps علاقه مند به مقیاس بندی سریع، کاهش خطاها و یافتن و رفع سریع خطاهای موجود هستند. بنابراین، اتوماسیون مفهومی است که در آن دو حوزه همگرا می شوند. مدیران سیستم مسئول خدمات ابری مانند AWS، Azure و Google Cloud Platform هستند. آنها باید اصول یکپارچه سازی و تحویل مداوم و نحوه استفاده از ابزارهایی مانند این را بدانند جنکینز.

علاوه بر این، مدیران سیستم باید از ابزارهای پیکربندی و مدیریتی مانند غیر ممکن، برای استقرار موازی ده یا بیست سرور ضروری است.

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

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

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

اگر شما یک مدیر سیستم هستید، پس باید Git را بهتر مطالعه کنید، نحوه ساخت کنترل نسخه را بدانید و دستورات رایج را به خاطر بسپارید: وضعیت git، git commit -m، git add، git pull، git push، git rebase، git branch، git diff و دیگران. دوره ها و کتاب های آنلاین زیادی وجود دارد که می تواند به شما کمک کند این موضوع را از ابتدا یاد بگیرید و با مهارت های خاص حرفه ای شوید. فوق العاده نیز وجود دارد برگه های تقلب با دستورات Git، بنابراین مجبور نیستید همه آنها را جمع کنید، اما هرچه بیشتر از Git استفاده کنید، آسان تر خواهد بود.

نتیجه

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

منبع: www.habr.com

اضافه کردن نظر