لماذا يجب التخطيط لتغييرات البنية التحتية قبل تطبيقها
أنت تراجع طلب سحب (Pull Request) يغير سطرًا واحدًا في ملف تكوين جدار الحماية. التغيير يفتح المنفذ 443 لحركة المرور العامة. بسيط بما فيه الكفاية، أليس كذلك؟
لكن هذا السطر الواحد قد يكون له عواقب لم تتوقعها. ربما تتعارض قاعدة أخرى معه. ربما تم إغلاق هذا المنفذ عمدًا لأسباب أمنية قبل ستة أشهر، ولا أحد يتذكر لماذا. ربما فتحه سيعطل اتصال قاعدة بيانات كان يمر عبر منفذ مختلف. لن تعرف أيًا من هذا حتى بعد تطبيق التغيير ويتوقف شيء عن العمل.
هذه هي الحالة بالضبط التي صُمم سير العمل "خطط-راجع-طبق" (Plan-Review-Apply) لمنعها.
المشكلة مع التطبيق المباشر
عندما تطبق تغييرات البنية التحتية مباشرة، فأنت تعمل بشكل أعمى. قد يكون لديك الكود أمامك، لكن الكود وحده لا يظهر لك ما سيحدث فعليًا عند تشغيله ضد بيئتك الحية. قد تكون الحالة الفعلية للبنية التحتية مختلفة عما يفترضه كودك. ربما قام شخص ما بتغيير يدوي الأسبوع الماضي. ربما ترك نشر سابق الأمور في حالة غير متوقعة. كودك يقول "أضف هذه القاعدة"، لكن النظام قد يفسر ذلك على أنه "استبدل جميع القواعد الموجودة بهذه القاعدة".
التطبيق المباشر يحول كل تغيير إلى مقامرة. تكتشف فقط أنك خسرت عندما تتعطل الأمور.
كيف يعمل سير العمل خطط-راجع-طبق
سير العمل له ثلاث مراحل، وكل منها يخدم غرضًا محددًا.
الرسم البياني أدناه يوضح التدفق:
خطط (Plan) يولد مقارنة مفصلة بين حالة البنية التحتية الحالية والحالة التي يريد كودك إنشاءها. يظهر بالضبط ما سيتم إضافته أو تعديله أو حذفه. هذا ليس ملخصًا أو تخمينًا. إنه فرق دقيق مولّد آليًا للبنية التحتية.
راجع (Review) هي حيث يفحص البشر تلك الخطة. تتحقق من المفاجآت. تتحقق من أن الخطة تطابق الهدف من التغيير. تكتشف أشياء مثل "هذا الحذف لمجموعة الأمان سيؤثر على خوادم الإنتاج" قبل أن يضغط أي شخص على زر التطبيق.
طبق (Apply) ينفذ التغييرات المخطط لها. نظرًا لأن الخطة تم التحقق منها بالفعل، فإن خطوة التطبيق لديها مخاطر أقل بكثير من النتائج غير المتوقعة. أنت لم تعد تخمن. أنت تنفذ مجموعة معروفة من التغييرات.
كيف تبدو الخطة فعليًا
الخطة ليست وصفًا غامضًا. إنها قائمة ملموسة من العمليات. على سبيل المثال، قد تظهر الخطة:
- إضافة قاعدة جديدة لمجموعة أمان للمنفذ 443
- تعديل مستمع موازن تحميل موجود لاستخدام شهادة جديدة
- حذف مجموعة فرعية لقاعدة بيانات لم يعد يشار إليها
تتضمن كل عملية معرف المورد (resource identifier)، والقيمة الحالية، والقيمة الجديدة. هذا المستوى من التفاصيل يسمح لك باكتشاف المشاكل قبل حدوثها. قد ترى أن الخطة تريد حذف مورد كنت تعتقد أنه غير مستخدم، أو تعديل إعداد تعتمد عليه فريق آخر.
جعل التخطيط شرطًا أساسيًا صارمًا
أكثر الفرق فعالية تعامل الخطة كخطوة غير قابلة للتفاوض. يتم تكوين خط أنابيبهم (pipeline) ليتوقف إذا لم يتم إنشاء خطة، أو إذا لم تتم مراجعة الخطة والموافقة عليها. هذا هو المعادل في البنية التحتية لاشتراط مراجعة الكود قبل دمج طلب السحب. لن تقوم بدمج كود غير مراجع في الإنتاج. فلماذا تطبق تغييرات بنية تحتية غير مراجعة؟
هذا الحاجز يمنع نمط الفشل الأكثر شيوعًا: شخص يقوم بتغيير صغير، يفترض أنه آمن، ويطبقه دون التحقق. يجبره خط الأنابيب على إنشاء خطة أولاً، والتي غالبًا ما تكشف شيئًا لم يتوقعه.
الخطط كسجلات تدقيق
تخدم الخطط غرضًا ثانيًا يصبح حاسمًا عندما تسوء الأمور. يمكن حفظ كل خطة كقطعة أثرية (artifact) في خط الأنابيب الخاص بك. هذا ينشئ سجلاً تاريخيًا لكل تغيير في البنية التحتية: ما الذي تغير، ومتى تغير، ومن وافق عليه.
عند حدوث حادث إنتاج، يكون هذا السجل لا يقدر بثمن. بدلاً من السؤال لمعرفة من غير ماذا، تنظر إلى القطع الأثرية للخطط. يمكنك رؤية الفرق الدقيق الذي تم تطبيقه قبل بدء المشكلة مباشرة. هذا يحول التحقيق في الحوادث من التخمين إلى تحليل قائم على الأدلة.
بدون الخطط المحفوظة، يتبقى لك سجلات يدوية ورسائل دردشة وذاكرة. لا شيء من هذا موثوق عندما تحاول تصحيح عطل إنتاجي في الساعة 2 صباحًا.
التعامل مع التغييرات المتزامنة
تواجه الفرق التي تعمل على نفس البنية التحتية تحديًا آخر: التغييرات المتضاربة. شخصان يعدلان ملفات تكوين الشبكة في نفس الوقت. كلا التغييرين يبدوان جيدين بشكل منفرد. لكن عند دمجهما، يخلقان تعارضًا قد يعطل الاتصال.
خطوة التخطيط تكتشف هذا. عندما يولد الشخص الثاني خطة، ستظهر التعارض قبل تطبيق أي تغييرات. يمكن للفريق حل التعارض في الكود، وليس في الإنتاج. هذا أكثر أمانًا بكثير من تطبيق كلا التغييرين والأمل في ألا يتفاعلا بشكل سيء.
ما لا تحله الخطة
سير العمل خطط-راجع-طبق قوي، لكن له حدود. يمكنه فقط مقارنة ما يقوله كودك مقابل ما تبلغ عنه البنية التحتية حاليًا. إذا قام شخص ما بتغيير يدوي خارج خط الأنابيب الخاص بك، فقد لا تكتشف الخطة كل التناقضات. إذا كان لدى مزود البنية التحتية لديك خطأ أو سلوك غير متوقع، فقد تظهر الخطة شيئًا مختلفًا عما يتم تنفيذه فعليًا.
هذه الحالات الحدودية لا تبطل سير العمل. إنها تعني فقط أنك بحاجة إلى ممارسات إضافية إلى جانبه، مثل كشف الانجراف (drift detection) والتوفيق المنتظم بين الكود والبنية التحتية الحية.
قائمة مراجعة عملية
قبل تنفيذ سير العمل خطط-راجع-طبق في خط الأنابيب الخاص بك، ضع في اعتبارك هذه النقاط:
- إنشاء الخطط تلقائيًا بعد كل طلب سحب مدمج، وليس فقط عند الطلب
- حفظ كل خطة كقطعة أثرية في خط الأنابيب مع الطوابع الزمنية وبيانات الموافقة
- منع التطبيق إذا لم توجد خطة أو إذا لم تتم مراجعة الخطة
- مراجعة الخطط بحثًا عن المفاجآت قبل الموافقة، وليس فقط للتحقق من الصحة
- استخدام الخطط أثناء التحقيق في الحوادث كمصدر أول للحقيقة للتغييرات الأخيرة
الفكرة الأساسية
سير العمل خطط-راجع-طبق يحول تغييرات البنية التحتية من مقامرات عمياء إلى عمليات محسوبة ومتحقق منها. الخطة تظهر لك ما سيحدث قبل أن يحدث. المراجعة تكتشف المشاكل قبل وصولها إلى الإنتاج. التطبيق ينفذ فقط ما تم التحقق منه. هذا سير العمل لا يزيل كل المخاطر، لكنه يزيل مخاطر تطبيق التغييرات دون معرفة تأثيرها الكامل.
إذا كان فريقك لا يزال يطبق تغييرات البنية التحتية مباشرة، ابدأ بقاعدة واحدة بسيطة: أنشئ خطة أولاً، اقرأها، وعندها فقط قرر ما إذا كنت ستطبق. هذه العادة الواحدة ستمنع مشاكل إنتاجية أكثر مما ستمنعه معظم أدوات المراقبة.