يحظى موضوع DevOps وIaC بشعبية كبيرة ويتطور بسرعة. ومع ذلك، فإن معظم المؤلفين يتعاملون مع مشاكل تقنية بحتة على طول هذا المسار. سأصف المشاكل المميزة لشركة كبيرة. ليس لدي حل - المشاكل بشكل عام قاتلة وتكمن في مجال البيروقراطية والتدقيق و"المهارات الناعمة".
نظرًا لأن عنوان المقالة بهذا الشكل، فإن Daenerys، التي انتقلت إلى جانب Enterprise، ستكون بمثابة القطة.
مما لا شك فيه أن هناك الآن تصادما بين القديم والجديد. وفي كثير من الأحيان في هذه الاصطدامات لا يوجد صواب أو خطأ. هكذا حدث الأمر. ولكن لكي لا نكون بلا أساس، سنبدأ بهذه الشاشة:
هذا هو ما يسمى طلب التغيير. ترى حوالي ثلث الحقول التي تحتاج إلى ملؤها من أدلة مختلفة، والحقول المتبقية موجودة في الإشارات المرجعية الأخرى. يجب ملء هذا المستند لتطبيق البرنامج النصي على خادم الإنتاج، أو تحميل ملفات جديدة، أو تغيير أي شيء بشكل عام.
عدد الحقول هو لدرجة أنني كتبت أتمتة صغيرة خاصة بي لملء هذه الحقول. علاوة على ذلك، تمت كتابة هذه الصفحة بطريقة لا يمكن لأي أدوات أتمتة رؤية حقولها، وكان الحل الوحيد الممكن هو استخدام AutoIt للنقر بغباء على الإحداثيات باستخدام الماوس. قم بتقييم مستوى يأسك للقيام بذلك:
لذلك، يمكنك استخدام Jenkins، وchef، وTerraform، وnexus، وما إلى ذلك، ونشرها جميعًا بكل سرور على جهاز التطوير الخاص بك. ولكن حان الوقت لإرسالها إلى QA وUAT وPROD. لديك قطعة أثرية من Nexus وتتلقى خطابًا من DBA يتضمن شيئًا مثل هذا:
عزيزي،
أولاً وقبل كل شيء، الرابطة التي يمكنك الحصول عليها لنفسك، لا يمكنني الوصول إلى الرابطة الخاصة بك
ثانيًا، يجب إصدار جميع التغييرات كطلب تغيير.
تحتاج إلى استخراج نصوص SQL النصية من Nexus وإرفاقها بطلب التغيير.
إذا لم يكن التغيير طارئًا، فيجب أن يتم ذلك قبل 7 أيام من الإصدار (حصريًا في عطلة نهاية الأسبوع)
عندما تتم الموافقة على طلب التغيير الخاص بك من قبل مجموعة من الأشخاص، سيقوم DBA بتنفيذ البرنامج النصي الخاص بك وحتى إرسال لقطة شاشة للنتيجة عبر البريد.مع أطيب التحيات، DBA الخاص بك الذي يعمل هنا منذ أيام الحاسوب المركزي.
هل تعرف بماذا يذكرني هذا؟ شبه آلية: يمسك الروبوت الإطار، ويضربه العامل بمطرقة ثقيلة. حسنًا، حقًا، ما الفائدة من هذا Nexus إذا تم كل شيء يدويًا بالكامل؟
لكن لا ينبغي إلقاء اللوم على إنتربرايز في هذا الأمر! إنه أمر دموي بالطبع، لكن كل هذه البيروقراطية مع طلبات التغيير مفروضة وتأتي من المدققين. يجب أن تعمل المؤسسة بهذه الطريقة، هذه النقطة. لا يمكنه فعل ذلك بأي طريقة أخرى. والتدقيق أمر متحفظ للغاية. على سبيل المثال، كم قيل عن حقيقة أن كلمات المرور الطويلة والمعقدة الزائفة والمتغيرة بشكل متكرر سيئة، ولكن المؤسسات ستكون المكان الأخير الذي سيتم فيه تغيير ذلك. أيضًا مع عمليات النشر وكل شيء آخر.
بالمناسبة، حاولت ذات مرة إنشاء ملف لـ Terraform، لكنه لم ينجح. لقد عثرت على معنى علامة "رمز فاتورة محاسبة المشاريع"، والتي لم أتمكن من اكتشافها مطلقًا - لم يكن لدي ما يكفي من المهارات الشخصية.
أنا لا أتناول حتى موضوع اللاضية السلبية - أوه، إن التشغيل الآلي الخاص بك يهدد أمن وظيفتي، ولا أريد أن أتعلم أي شيء جديد، لذلك سأقوم بتخريبه بهدوء.
حسنًا، ما هو الحل من حيث المبدأ؟ يحتوي نظام ITSM على واجهة برمجة تطبيقات بدائية للغاية لإنشاء المستندات تلقائيًا. وبشكل عام، تأتي معظم هذه الأنظمة من زمن الحواسيب المركزية. هل يعرف أحد أي أنظمة ITSM حديثة حقًا؟ هل لدى أي شخص تجربة ناجحة في دمج DevOps الحديثة والبيروقراطية؟ نحن، بالطبع، لا نتحدث عن مواقع المبيعات البحتة، حيث يمكن أن يكون هناك بالفعل نشر كل يوم، ولكن، على سبيل المثال، القطاع المصرفي، الذي يخضع لمراجعي الحسابات وعزلة قوية للغاية في البيئات الأعلى.
فقط لا تنس أن كل خيالاتك محدودة بالمراجعة. وهذا يغير كل شيء. أنا في انتظاركم في التعليقات!
المصدر: www.habr.com