موضوع DevOps و IaC بسیار محبوب است و به سرعت در حال توسعه است. با این حال، بیشتر نویسندگان در این مسیر با مشکلات صرفاً فنی سروکار دارند. من مشکلات مشخصه یک شرکت بزرگ را شرح خواهم داد. من راه حلی ندارم - مشکلات، به طور کلی، کشنده هستند و در حوزه بوروکراسی، حسابرسی و "مهارت های نرم" قرار دارند.
از آنجایی که عنوان مقاله اینگونه است، دنریس که به سمت اینترپرایز رفته است نقش گربه را بازی می کند.
بدون شک اکنون برخورد قدیم و جدید وجود دارد. و اغلب در این برخوردها نه درست است و نه باطل. فقط به آن صورت اتفاق افتاد. اما، برای اینکه بی اساس نباشیم، با این صفحه شروع می کنیم:
این به اصطلاح درخواست تغییر است. شما حدود یک سوم فیلدهایی را می بینید که باید از دایرکتوری های مختلف پر شوند، فیلدهای باقی مانده در نشانک های دیگر هستند. برای اعمال اسکریپت در سرور تولید، یا آپلود فایل های جدید یا به طور کلی تغییر هر چیزی، چنین سندی باید پر شود.
تعداد فیلدها به حدی است که من اتوماسیون کوچک خودم را برای پر کردن این فیلدها نوشتم. علاوه بر این، این صفحه به گونه ای نوشته شده است که هیچ ابزار اتوماسیونی نمی تواند فیلدهای آن را ببیند و تنها راه حل ممکن استفاده از AutoIt برای کلیک احمقانه روی مختصات با ماوس بود. سطح ناامیدی خود را برای انجام این کار ارزیابی کنید:
بنابراین، شما جنکین، سرآشپز، ترافورم، نکسوس و غیره را می گیرید و با خوشحالی همه را در برنامه نویس خود مستقر می کنید. اما زمان ارسال آن به QA، UAT و PROD فرا رسیده است. شما یک مصنوع Nexus دارید و نامه ای از DBA با چیزی شبیه به این دریافت می کنید:
عزیز،
اول از همه، نکسوس شما که می توانید برای خودتان داشته باشید، من به نکسوس شما دسترسی ندارم
در مرحله دوم، تمام تغییرات باید به عنوان یک درخواست تغییر صادر شود.
شما باید اسکریپت های SQL را از Nexus استخراج کرده و به درخواست تغییر پیوست کنید.
اگر تغییر اضطراری نیست، این باید 7 روز قبل از انتشار (به طور انحصاری در آخر هفته) انجام شود.
هنگامی که درخواست تغییر شما توسط تعدادی از افراد تایید شد، DBA اسکریپت شما را اجرا می کند و حتی یک تصویر از نتیجه را از طریق پست ارسال می کند.با احترام، DBA شما که از زمان مین فریم اینجا کار کرده است.
میدونی این منو یاد چی میندازه؟ نیمه اتوماسیون: ربات قاب را نگه می دارد و کارگر با پتک به آن ضربه می زند. خوب، واقعاً اگر همه چیز کاملاً دستی انجام شود، این نکسوس چه فایده ای دارد؟
اما نباید Enterprise را در این مورد سرزنش کرد! البته خونین است، اما این همه بوروکراسی با درخواست های تغییر اجباری است و از سوی حسابرسان می آید. شرکت باید به این روش کار کند، دوره. او نمی تواند این کار را به روش دیگری انجام دهد. و حسابرسی یک چیز بسیار محافظه کارانه است. به عنوان مثال، چقدر در مورد این واقعیت گفته شده است که رمزهای عبور شبه پیچیده و مکرر تغییر یافته بد هستند، اما شرکت ها آخرین جایی هستند که این رمز عبور تغییر خواهد کرد. همچنین با استقرار و هر چیز دیگری.
به هر حال، یک زمانی سعی کردم یک فایل برای terraform ایجاد کنم، اما کار نکرد. من به طور تصادفی متوجه معنی برچسب "کد صورتحساب حسابداری پروژه" شدم، که هرگز موفق به کشف آن نشدم - مهارت های نرم کافی نداشتم.
من حتی به موضوع لودیسم منفعل هم نمی پردازم - اوه، اتوماسیون شما امنیت شغلی من را تهدید می کند، من نمی خواهم چیز جدیدی یاد بگیرم، بنابراین بی سر و صدا آن را خراب می کنم.
خب اصولا راه حل چی میتونه باشه؟ سیستم ITSM یک API بسیار ابتدایی برای تولید خودکار اسناد دارد. و به طور کلی اکثر این سیستم ها از زمان مین فریم ها می آیند. آیا کسی سیستم های واقعا مدرن ITSM را می شناسد؟ آیا کسی تجربه موفقی در ادغام DevOps مدرن و بوروکراسی دارد؟ ما البته در مورد سایت‌های صرفاً فروش صحبت نمی‌کنیم، که در واقع می‌تواند هر روز در آن مستقر شود، بلکه، به عنوان مثال، بخش بانکی است که زیر نظر حسابرسان و انزوای بسیار قوی در محیط‌های بالاتر است.
فقط فراموش نکنید که تمام خیالات شما توسط ممیزی محدود می شود. و این همه چیز را تغییر می دهد. در نظرات منتظر شما هستم!
منبع: www.habr.com