🏿 🧗🏾 👲🏻 كيف يقوم OpenShift بتغيير الهيكل التنظيمي لمؤسسة تكنولوجيا المعلومات. تطور النماذج التنظيمية عند الانتقال إلى PaaS 🎅🏼 ✴️ 🍍

على الرغم من أن حلول PaaS (النظام الأساسي كخدمة) وحدها غير قادرة على تغيير طرق التفاعل الفردي والجماعي ، إلا أنها غالبًا ما تكون بمثابة حافز للتغيير التنظيمي استجابة للمرونة المتزايدة لتقنيات تكنولوجيا المعلومات.

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

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

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

ربط الوظائف الجديدة بالأدوار القديمة

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

نحو منظمة DevOps

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

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

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

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

التحديات الجديدة التي تواجهها مؤسسات تكنولوجيا المعلومات عند الانتقال إلى OpenShift

في هذا القسم ، سنلقي نظرة على الأدوار والمهام التي تستخدمها المؤسسات التي تحولت إلى OpenShift عادةً لتسريع الأتمتة والخدمة الذاتية باستخدام التكنولوجيا و PaaS.

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

جدول 1. تعريفات مهمة OpenShift

مهام	المهارات المطلوبة
(provisioning) - :	- Linux
OpenShift :	Linux (Ansible) Kubernetes OpenShift
(tenant provisioning), - : RBAC	Kubernetes OpenShift , ,
:	Linux runtime- middleware (application build frameworks) , imagestream
:	immutable – , . . OpenShift, buildconfigs, deploymentconfigs, services, routes, configmaps
:	(cloud native)
: ( ) -
: UI ( )	أطر الاختبار قوالب تصميم التطبيق

أدوار جديدة تنشأ في مؤسسات تكنولوجيا المعلومات عند الترحيل إلى OpenShift

بينما تنتقل إلى النموذج التنظيمي القائم على DevOps ، يميل عدد تخصص الأدوار إلى التناقص ، ويتزايد عدد الفرق والأدوار متعددة الوظائف بدوره لزيادة التعاون إلى أقصى حد. هنا ، في رأينا ، قائمة المواقف الرئيسية في مؤسسة تكنولوجيا المعلومات باستخدام OpenShift:

مهندس عمليات التطبيق أو مهندس موثوقية الموقع. في السابق ، كان يمكن تسمية هذا الموضع بـ "مسؤول خادم التطبيق".
مطور تطبيقات / مطور برامج / مهندس برمجيات.
مسؤول النظام الأساسي للكتلة / التطبيق. في السابق ، كان يمكن تسمية هذا الدور "مسؤول النظام" أو "مسؤول النظام الأساسي لنظام Linux".
مدير إصدار البرامج (مهندس البناء).

مصفوفة دور RACI ومهامها

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

مهام	الأدوار
مهام	مهندس عمليات التطبيق / مهندس موثوقية الموقع	مطور تطبيقات / مطور برامج / مهندس برمجيات	مسؤول النظام الأساسي للكتلة / التطبيق	مدير إصدار البرمجيات / مهندس التجميع
أتمتة وتوفير البنية التحتية لتكنولوجيا المعلومات	أنا	أنا	ص / أ	ج
تثبيت وإدارة منصة OpenShift	ج	أنا	ص / أ	ج
تصميم وإدارة خطوط النشر	ج	ج	أنا	ص / أ
إدارة توفير المستأجر والعزل وقدرات تكنولوجيا المعلومات	ج	أنا	ص / أ	أنا
بناء وإدارة الصور الأساسية	ص	ج	ص / أ	ج
تطوير التطبيق والاختبار	ج	ص / أ	أنا	أنا
المراقبة التشغيلية وإدارة التطبيقات	ص / أ	ج	ج	أنا
اختبار القبول الجمركي	ج	ص	أنا	أنا

اتفاقيات في مصفوفة RACI
المصدر: ويكيبيديا

المسؤول - المنفذ هو الذي يفعل ما هو ضروري لإكمال المهمة.
Accountable – – , ; , .
Consulted – – , , ; .
Informed – – , (, ); .

DevOps-

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

الشكل 1. تنظيم تكنولوجيا المعلومات التقليدية

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

الشكل 2 الشكل 2. DevOps تنظيم تكنولوجيا المعلومات

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

تلخيص

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

كيف يقوم OpenShift بتغيير الهيكل التنظيمي لمؤسسة تكنولوجيا المعلومات. تطور النماذج التنظيمية عند الانتقال إلى PaaS