حول DevOps وندفات الثلج

بالكاد يمكنك التحرك في عالم تقنية المعلومات هذه الأيام دون أن تسمع الناس يتحدثون عن DevOps. يُعدّ DevOps الموضوع الساخن الجديد في الصناعة، آخذًا الراية من حيث توقف الحديث عن الحوسبة السحابية، ولو صدّقت ما يقوله الناس لاعتقدت أن إدارة الأنظمة التقليدية قد ماتت ودُفنت.

أولًا ينبغي أن نتحدث عما نعنيه بـ DevOps. قد يكون هذا مُلتبِسًا لأنه، شأنه شأن الحوسبة السحابية، كثيرًا ما يُستعار مصطلح قديم ليعني شيئًا مختلفًا أو على أحسن تقدير ذا صلة بشيء موجود أصلًا. كان DevOps التقليدي يعني الجمع بين دوري المطوّر والمشغِّل. في الفترة الممتدة من الستينيات إلى التسعينيات، كان هذا الأسلوب المعياري في تشغيل الأنظمة. في هذا العالم كان الأشخاص الذين يكتبون البرامج عمومًا أنفسهم من ينشرونها ويصونونها. ومن هنا جاء الجمع بين «المطوّر» و«التشغيل»، إذ التشغيل مصطلح شبه معياري لدور مدير الأنظمة. لم تكن هذه الأدوار منفصلة في الغالب حتى ظهور «قسم تقنية المعلومات» في التسعينيات والألفينيات. ومنذ ذلك الحين بدأ اتجاه العودة إلى الجمع بين الدورين يتصاعد مجددًا في الشعبية، وذلك أساسًا بسبب الطريقة التي يمكن بها للدورين العمل معًا بقيمة مضافة كبيرة في كثير من بيئات تطبيقات الويب المستضافة الحديثة.

حيثما يُتحدث عن DevOps اليوم في الغالب فذلك ليس بوصفه اندماجًا صارمًا بين المطوّرين وطاقم التشغيل، بل بوصفه تعديلًا على طاقم التشغيل مع تركيز أعلى بكثير على الترميز، ليس في التطبيق ذاته بل في تعريف بنى التطبيقات التحتية بوصفها شيفرة برمجية امتدادًا طبيعيًا لبنى الحوسبة السحابية. قد يكون هذا مُلتبِسًا في البداية. المهم ملاحظة أن DevOps التقليدي ليس ما يجري في الغالب اليوم، بل ثمة DevOps «مزيّف» جديد يبقى فيه المطوّرون مطوّرين ويبقى التشغيل تشغيلًا، لكن التشغيل تطوّر إلى دور جديد «ثقيل الترميز» يواصل التركيز على إدارة الخوادم التي تشغّل الشيفرة المقدَّمة من المطوّرين.

ما يُعدّ مهمًا اليوم هو أن دور مدير الأنظمة بدأ ينقسم إلى دورين ذوي صلة لكن مختلفَين بشكل ملحوظ، أحدهما يُسمّى خطأً DevOps من قِبَل معظم الصناعة اليوم (إذ إن معظم الصناعة أصغر من أن تتذكر حين كان DevOps هو القاعدة لا الاستثناء، وبالتأكيد لم يكن شيئًا جديدًا ومبتكرًا). أشير إلى هذين الجانبين من دور مدير الأنظمة هنا بمقاربتَي DevOps وندفة الثلج.

أستخدم مصطلح ندفة الثلج للإشارة إلى البنى التقليدية للأنظمة لأن كل خادم منفرد يمكن رؤيته بوصفه «ندفة ثلج فريدة.» كلها مختلفة، على الأقل بمعنى أنها لا تُدار بطريقة تُبقيها متطابقة. لا يعني ذلك بالضرورة أنها يجب أن تكون جميعها فريدة، بل أنها تحتفظ بالقدرة على أن تكون كذلك. في البيئات التقليدية يقوم مدير الأنظمة بتسجيل الدخول إلى كل خادم منفردًا للعمل عليه. ثمة قدر من السكريبت البرمجي الشائع لتسهيل مهام الإدارة، لكن في جوهره الدور يستلزم قضاء وقت كبير في العمل على الأنظمة الفردية.

كثيرًا ما اشتملت تسهيل إدارة بنى ندفة الثلج على محاولات لتقليل الاختلافات بين الأنظمة بطرق معقولة. هذا يبدأ عمومًا بأشياء كاختيار نظام تشغيل قياسي واحد وإصدار محدد (Windows 2012 R2 أو Red Hat Enterprise Linux 7) بدلًا من السماح لكل تثبيت خادم بأن يكون نظام تشغيل أو إصدارًا مختلفًا. قد يبدو هذا التوحيد أساسيًا، لكن كثيرًا من المؤسسات تفتقر إلى هذا التوحيد حتى اليوم.

خطوة تالية شائعة هي إنشاء منهجية نشر قياسية أو صورة ذهبية رئيسية تُستخدم لإعداد جميع الأنظمة بحيث تكون نظام التشغيل الأساسي وجميع الحزم الأساسية، وكثيرًا ما تشمل تخصيص النظام وحزم المراقبة وحزم الأمان وإعداد المصادقة وتعديلات مماثلة، قياسيةً ومنشورةً بصورة موحّدة. يوفّر ذلك نقطة انطلاق مشتركة لجميع الأنظمة لتقليل التباين. لكنها من الناحية التقنية لا تضمن إلا نقطة انطلاق قياسية ويجب توقّع تباين في الإعدادات بمرور الوقت.

فيما وراء هذه الخطوات، تستخدم بيئات ندفة الثلج عادةً سكريبتات إدارة مخصصة أو أدوات إدارة لصون قدر من التوحيد بين الأنظمة بمرور الوقت. كلما كانت القواسم المشتركة بين الأنظمة أكثر كانت أسهل في الصيانة وتشخيص الأعطال وأقل المعرفة الواجبة على طاقم الإدارة. المزيد من التوحيد يعني مفاجآت أقل ومجاهيل أقل وقدرات اختبار أفضل بكثير.

في بيئة مدير أنظمة فردي مع ممارسات وأدوات جيدة، يمكن لبيئات ندفة الثلج أن تبلغ درجة عالية من التوحيد. لكن في البيئات التي يعمل فيها مديرو أنظمة كثيرون، ولا سيما أولئك المدعومون على مدار الساعة من مناطق متعددة، ومع عدد كبير من الأنظمة، يمكن أن يصبح التوحيد صعبًا جدًا حتى مع أشد الممارسات حرصًا. وهذا حتى قبل أن نتطرق إلى الإشكاليات الواضحة المتعلقة بأن حزمًا مختلفة وربما إصدارات مختلفة من الحزم مطلوبة على الأنظمة التي تؤدي أدوارًا مختلفة.

تنمو مقاربة DevOps عضويًا من نموذج بنية الحوسبة السحابية. بنية الحوسبة السحابية مصممة حول أنظمة مُنشأة تلقائيًا ومُدمَّرة تلقائيًا، متطابقة على نطاق واسع (على الأقل في مجموعات) وتُتحكّم بها عبر واجهة برمجية أو API. يُلائم هذا النموذج بشكل جليّ التحكم المركزي عبر نظام إدارة بدلًا من الجهود اليدوية لمدير الأنظمة. الإدارة اليدوية مستحيلة فعليًا وغير عملية تمامًا في ظل هذا النموذج. الأنظمة الفردية ليست فريدة كما في نموذج ندفة الثلج وأي تباين سيخلق مشاكل جسيمة.

الفكرة التي نشأت من عالم بنية الحوسبة السحابية هي أن بنية الأنظمة ينبغي تعريفها مركزيًا «في شيفرة برمجية» بدلًا من على الخوادم ذاتها. يبدو هذا مُلتبِسًا في البداية، لكنه منطقي جدًا حين ننظر فيه بعمق. لدعم هذا النموذج بدأ يظهر نوع جديد من أدوات إدارة الأنظمة لم يستقر على اسم معياري حتى الآن لكنه كثيرًا ما يُسمّى أداة أتمتة الأنظمة أو إطار DevOps أو أداة أتمتة تقنية المعلومات أو ببساطة أداة «البنية التحتية كشيفرة برمجية». تشمل مجموعات الأدوات الشائعة في هذا المجال Puppet وChef وCFEngine وSaltStack.

الفكرة الكامنة وراء مجموعات الأدوات الآلية هذه هي استخدام خدمة مركزية لإدارة جميع الأنظمة والتحكم فيها. تدير هذه السلطة المركزية الخوادم الفردية عبر وصفات قائمة على الشيفرة تُحدّد كيف ينبغي أن يبدو النظام ويتصرف. في عالم Chef، تُسمّى هذه «وصفات» بدلًا من «ملفات الإعداد»، والتشبيه ملائم. قد تتضمن شيفرة كل نظام معلومات كقائمة الحزم وإصداراتها التي ينبغي تثبيتها وإعدادات النظام التي ينبغي تعديلها والملفات المراد نسخها إلى الخادم. في كثير من الحالات، تُعالَج القرارات المتعلقة بعمليات النشر أو التعديلات هذه من خلال منطق بالغ التعقيد، ومن هنا الحاجة إلى شيفرة برمجية فعلية بدلًا من شيء أبسط كلغة ترميز أو قوالب. ثم تُجمَّع الأنظمة حسب الدور وتُدار كمجموعات. قد يُملي دور «خادم الويب» على مجموعة من الأنظمة تثبيت Apache وPHP وإعداد الذاكرة بحيث لا يتبادلها. أما دور «SQL Server» فقد يُثبّت MS SQL Server وأدوات نسخ احتياطي خاصة تُستخدم لذاك التطبيق فقط ويُعدّ الذاكرة حسب الرغبة لمجموعة من أجهزة SQL Server. هذه مجرد أمثلة. عادةً تمتلك المؤسسة أدوارًا كثيرة، بعضها عام كـ «خادم الويب» وبعضها أكثر تحديدًا لدعم تطبيقات بعينها. يمكن عمومًا تراكم الأدوار، فقد يكون النظام «خادم ويب» و«خادم Java» في آنٍ معًا مستوفيًا الاحتياجات المجمّعة لكليهما.

تعني هذه التعريفات القياسية أن الأنظمة، بمجرد تعيينها لدور أو آخر، يمكنها «بناء نفسها» تلقائيًا. قد يُنشأ نظام جديد بطلب من مدير أو قد يُقرّر نظام مراقبة السعة أن سعة إضافية مطلوبة لدور ما فيُولّد نسخًا جديدة من الخوادم تلقائيًا دون أي تدخل بشري على الإطلاق. في اللحظة التي يُطلب فيها النظام، من إنسان أو تلقائيًا، يُعيَّن الدور وسيتحوّل النظام، عبر إطار الأتمتة، إلى «عقدة» مُهيَّأة ومُحدَّثة بالكامل. لا حاجة إلى تدخل بشري في إدارة الأنظمة. العملية سريعة وبسيطة والأهم قابلة للتكرار الكامل.

تعريف الأنظمة بشيفرة برمجية له نتائج غير واضحة للوهلة الأولى. إحداها أن النسخ الاحتياطي للأنظمة الكاملة لم يعد ضروريًا. لماذا تحتفظ بنسخة احتياطية لنظام يمكنك إعادة إنشائه، بجهد ضئيل، شبه فوري؟ البيانات المحلية من أنظمة قواعد البيانات ستحتاج إلى نسخ احتياطي، لكن بيانات قاعدة البيانات فقط، لا النظام بأكمله. هذا يمكن أن يُخفّف الضغط على بنى النسخ الاحتياطي بشكل كبير ويجعل عمليات الاستعادة أسرع وأكثر موثوقية.

كمية التوثيق اللازمة للأنظمة المعرَّفة بالفعل في شيفرة برمجية ضئيلة جدًا. في بيئات ندفة الثلج، يحتاج مدير الأنظمة إلى الحفاظ على توثيق خاص بكل مضيف وتحديث ذلك التوثيق يدويًا. هذا يستهلك وقتًا كبيرًا وعرضة للأخطاء. الأنظمة المعرَّفة عبر شيفرة مركزية تحتاج إلى توثيق قليل أو لا تحتاج إليه، ويمكن التعامل مع التوثيق على مستوى المجموعة لا مستوى العقدة الفردية.

اختبار الأنظمة المعرَّفة بشيفرة برمجية سهل أيضًا. يمكنك إنشاء نظام عبر الشيفرة واختباره وأنت تعلم أنه حين تنقل هذا التعريف إلى بيئة الإنتاج، سيُنشأ نظام الإنتاج بصورة قابلة للتكرار بالضبط كما أُنشئ في الاختبار. في بيئات ندفة الثلج من الشائع جدًا وجود ممارسات اختبار تحاول تحقيق ذلك لكن عبر جهود يدوية، وهي عرضة للتسيّب وعدم الدقة في التكرار وكثيرًا ما تُملي السياسة الداخلية أنه أسرع محاكاة قابلية التكرار بدلًا من السعي الحقيقي إليها. الأنظمة المعرَّفة بشيفرة برمجية تتجاوز هذه الإشكاليات مما يجعل الاختبار أكثر قيمة بكثير.

فيما وراء الحاجة إلى تعريف عدد من العقد الموجودة ضمن كل دور، يمكن للنظام إعادة توفير بنية تحتية كاملة من الصفر تلقائيًا. يمكن إجراء إعادة البناء بعد كارثة أو تشغيل موقع ثانوي بسرعة وسهولة بالغتين. كذلك الانتقال بين الأنظمة المستضافة محليًا والمستضافة عن بُعد بما فيها تلك من شركات كـ Amazon وMicrosoft وIBM وRackspace وغيرها سهل للغاية.

بالطبع، في عالم DevOps تكتسب بنى الحوسبة السحابية قيمة عظيمة في تمكين أقصى درجات الأتمتة، لكن استخدام بنى الحوسبة السحابية ليس ضروريًا للاستفادة من هذا النوع من الأدوات. وبالطبع، يمكن استخدام البنية المعرَّفة بشيفرة برمجية جزئيًا بينما تُنفَّذ الإدارة اليدوية أيضًا في مقاربة هجينة، لكن هذا نادرًا ما يُوصى به على الأنظمة الفردية. من الأفضل عمومًا وجود بيئتين، إحداهما تُدار كندفة ثلج والأخرى كـ DevOps حين يكون كلا الأسلوبين مطلوبَين. هذا يصنع هجينًا أفضل بكثير. لقد رأيت هذا يُجدي نفعًا جيدًا في بيئة مؤسسية بعشرات الآلاف من خوادم «ندفة الثلج» الفريدة جدًا، مع بيئة مخصصة من عشرات الآلاف من العقد تُدار بأسلوب DevOps لأن جميع العقد يجب أن تكون متطابقة وقابلة للتبديل باستخدام أحد إعدادَين ممكنَين. كان التهجين فعّالًا جدًا.

لكن مقاربة DevOps تأتي مع تحفظات جوهرية أيضًا. مجموعات المهارات اللازمة لإدارة نظام بهذه الطريقة أكبر بكثير من تلك اللازمة لإدارة الأنظمة التقليدية، إذ تبقى الحاجة كحدٍّ أدنى إلى كل معرفة إدارة الأنظمة التقليدية بالإضافة إلى معرفة برمجية متينة عادةً بلغات حديثة كـ Python وRuby ومعرفة بالأطر المحددة المعنية. هذا التوسع في قاعدة المعرفة يعني أن ممارسي DevOps ليسوا نادرين فحسب بل مكلفون أيضًا. كما يعني أن التعليم الجامعي، البعيد أصلًا عن تأهيل مديري الأنظمة أو المطوّرين للعالم المهني، يغدو أبعد من ذلك في تأهيل الخريجين للعمل في ظل نموذج DevOps.

يميل مديرو الأنظمة العاملون في كل من هذين المعسكرين إلى رؤية جميع الأنظمة بوصفها بحاجة إلى الاندراج في قالبهم الخاص. ممارسو DevOps الجدد كثيرًا ما يعتقدون أن أنظمة ندفة الثلج موروثة وتحتاج إلى التحديث. مديرو ندفة الثلج (التقليديون) يميلون إلى رؤية حركة «البنية التحتية كشيفرة برمجية» بوصفها سخيفة مثقلة بعبء غير ضروري ومعقدة للغاية ومحدودة النطاق.

الواقع هو أن كلتا المقاربتين تتمتعان بقدر هائل من المزايا وكلتاهما ستبقيان قابلتَين للتطبيق بشكل كبير. كلتاهما منطقيتان لأعباء عمل مختلفة جدًا، والمؤسسات الكبيرة، أظنّ، ستشهد الاثنتين بشكل شائع عبر شكل من أشكال التهجين. في سوق الشركات الصغيرة والمتوسطة (SMB) حيث لا توجد إلا أعداد ضئيلة من الخوادم ولا رافعة للتوسع لتبرير بنى الحوسبة السحابية وتباين عالٍ بين الأنظمة، أظنّ أن DevOps سيبقى خارج نطاق القاعدة إلى أجل غير مسمّى إذ إن العبء والمهارات الإضافية اللازمة لتشغيله غير عملية أو مستحيلة الاكتساب. على المؤسسات الأكبر النظر في أعباء عملها. أعباء عمل تقليدية كثيرة وكثير من البرمجيات التقليدية غير مناسبة لمقاربة DevOps، ولا سيما أتمتة الحوسبة السحابية، وإما ستستلزم التهجين أو مستوى باهظًا من الترميز بحسب كل نظام مما يجعل نموذج DevOps مستحيل التبرير. لكن أعباء العمل المبنية على بنى الويب أو القادرة على التوسع الأفقي الممتاز ستستفيد استفادة جوهرية من نموذج DevOps على نطاق واسع. يمكن أن ينطبق هذا على شركات مؤسسية كبيرة أو شركات أصغر تُنتج على الأرجح تطبيقات مستضافة للاستهلاك الخارجي.

يعني هذا الاختلاف في المقاربة أنه في الولايات المتحدة مثلًا، تتألف غالبية البلاد من شركات ستبقى مركّزةً على نموذج إدارة ندفة الثلج، بينما يمكن لبعض الشركات على الساحل الشرقي تقييم نموذج DevOps بفعالية والبدء في التحرك نحوه. لكن على الساحل الغربي حيث البنى الأكثر حداثةً والتركيز الأكبر على التطبيقات المستضافة وتطبيقات الاستهلاك الخارجي هي العوامل الاقتصادية الدافعة، ينتقل DevOps من الحداثة إلى النضج والطبيعية الراسخة. ستبقى مقاربتا DevOps وندفة الثلج مفصولتَين بشكل حادّ جغرافيًا على الأرجح، تمامًا كما تشهد تقنية المعلومات عمومًا هجرة مهارات مختلفة إلى مناطق مختلفة. لن يكون مفاجئًا رؤية DevOps يبدأ الترسّخ في أسواق كأوستن حيث أدّت تقنية المعلومات التقليدية أداءً متواضعًا نسبيًا.

لا أحد من المقاربتين أفضل أو أسوأ، فهما مقاربتان مختلفتان تخدمان طريقتَين مختلفتَين جدًا في توفير الأنظمة واحتياجَين أساسيَّين مختلفَين لتلك الأنظمة. مع ظهور بنى الحوسبة السحابية ونموذج DevOps، من الأهمية الحيوية أن يفهم مديرو الأنظمة الحاليون ما يعنيه نموذج DevOps ومتى ينطبق حتى يتمكنوا من تقييم أعباء عملهم الخاصة واحتياجاتهم الفريدة بشكل صحيح. سيهاجر جزء كبير من عالم إدارة أنظمة ندفة الثلج التقليدي، عبر الوقت، إلى نموذج DevOps. نحن بعيدون جدًا عن الوصول إلى حالة توازن مستقرة في الصناعة فيما يخص توازن هذين النموذجين.

نُشر في الأصل على مدونة StorageCraft.