تحية للجميع! اسمي تيمور جيلمولين ، أنا نائب رئيس قسم التقنيات وعمليات التطوير في شركة التقنيات الإيجابية ، وأنا منخرط في الأتمتة وتنفيذ أفكار DevOps. سأخبرك اليوم كيف دخلت المهنة ، وكيف نرى في قسمنا مهنة مهندس DevOps ، وما هي خريطة الكفاءات ، وكيف تساعد على ضمان نمو الموظفين.تنصل
هذه المقالة ليست محاولة لوصف المسار الوظيفي المثالي لمهندس DevOps. هدفنا هو مشاركة الخبرة وإخبارنا كيف يعمل معنا. هناك شركات متخصصة ( التعبير عن 42 ، flant ) ومجتمعات ( devops deflope ) التي تقدم مساهمة كبيرة في تطوير أفكار DevOps في روسيا ، وقد اخترنا مجموعة من التقنيات والتقنيات المناسبة لنا.حول كيفية تطوير أفكار DevOps في إدارتنا وفي الشركة ، يمكنك القراءة على Habré:والآن ، دعنا نذهب!لماذا نحتاج DevOps
لكل شركة تفاصيلها الخاصة في قسم الأتمتة. كقاعدة ، يتم نقل تلك المهام التي تكون صعبة أو مكلفة للغاية على مستوى عدة أقسام منفصلة إلى مجموعة مركزية أو قسم التشغيل الآلي. في شركتنا ، الهدف العالمي من تنفيذ أفكار DevOps هو ضمان خفض ثابت في تكلفة الإنتاج ودعم المنتج من حيث الكمية (ساعات العمل أو ساعات الماكينة ، وحدة المعالجة المركزية ، ذاكرة الوصول العشوائي).بناءً على هذا الهدف ، تم إبراز دور قسم الأتمتة على مستوى الشركة بأكملها - وذلك لتقليل تكلفة أداء المهام التسلسلية النموذجية في جميع مراحل الإنتاج.كيف تعمل
كما تعتمد المسؤوليات الوظيفية لأقسام الأتمتة اعتمادًا كبيرًا على تفاصيل شركة معينة. شركتنا هي مطور وبائع حلول أمن المعلومات ، وقسم الأتمتة مسؤول عن ناقل الإنتاج - من تجميع المكونات الفردية للمنتجات إلى إرسالها للاختبار وتقديم تحديثات للبنية التحتية للعميل. نساعد في أتمتة عمليات التطوير الرئيسية في الفرق ونضمن أداء أنظمتنا (التكامل المستمر والتسليم المستمر (CI / CD)).ينقسم عملنا إلى عدة مجالات وظيفية. يدعم اتجاه التكامل المستمر خطوط التجميع والاختبار للمطورين والمختبرين. يعمل اتجاه البنية التحتية في التشغيل والاستخدام الأمثل لجميع موارد "الحديد" الخاصة بالقسم ، بالإضافة إلى أتمتة نشر الأجهزة الافتراضية وبيئتها (البنية التحتية كرمز). يوفر اتجاه المراقبة التحكم في التوافر اليومي للخدمات. كما نقدم المراقبة كخدمة للمطورين (المراقبة كخدمة).يوفر اتجاه سير العمل للفرق أدوات لإدارة عمليات التطوير والاختبار ، وتحليل حالة الشفرة والحصول على تحليلات المشروع. وأخيرًا ، يوفر webdev إصدارات النشر على خوادم تحديثات الشركات (GUS و FLUS) ، بالإضافة إلى ترخيص المنتجات باستخدام خدمة Licence Lab.لدعم خط أنابيب الإنتاج ، قمنا بإعداد وصيانة العديد من خدمات الدعم المختلفة للمطورين. يمكن سماع قصص عن بعضها على صفحاتنا القديمة: Op! DevOps! 2016 و Op! DevOps! 2017 . نقوم أيضًا بتطوير أدوات الأتمتة الداخلية ، بما في ذلك DevOpsHQ .
تجربة مهندسينا
يتمتع الأشخاص من قسم الأتمتة لدينا (للبساطة ، ويسمى قسم DevOps بشكل غير رسمي) بخلفية مختلفة تمامًا: هناك مختبرين سابقين ومبرمجين ومهندسين ومسؤولي تكنولوجيا المعلومات. أنا مدرس دبلوم في الرياضيات وعلوم الكمبيوتر. كما اتضح ، بفضل تنوع الخبرة ، تمكنا من التعامل مع مهام جميع مجالاتنا.لا يوجد مهندس واحد في قسمنا يمكنه حل جميع المشاكل بمفرده في جميع المجالات. ولكننا معا ، كوحدة إدارية ، وبالتالي نحن SRE(ليس فقط موقعًا ، مهندسي موثوقية الخدمات ، لأننا ندعم خدمات المطورين) ، والتي يبحث عنها متخصصو الموارد البشرية في شخص مهندس واحد دون جدوى. نحن نعتقد أنه لا يمكن حل مجموعة واسعة من مهام المنتج للشركة إلا كجزء من فريق من المهندسين المتنوعين.لدينا العديد من الحالات الفنية لتنفيذ الأتمتة. ولكن الشيء الرئيسي هو أن يشرح للناس لماذا يحتاجون إلى هذه الأتمتة. أسهل طريقة هي عندما تأتي المهمة الفنية من الأعمال ، أي عندما يكون لدى الأشخاص الذين يجلبون المال للشركة فهم واضح: ماذا وكيف ومتى يفعلون أو يحسنون. أقترح عليك أن تنظر إلى حالات الأتمتة لدينا: " تجربة شخصية: كيف يبدو نظام التكامل المستمر لدينا ."حول مهنة في قسم DevOps
أود أن أقول إن كل شيء كان جاهزًا ومخططًا له مسبقًا ، لكن الأمر ليس كذلك. في البداية ، لم يكن لدينا شيء في خططنا للنمو والتنمية. في عام 2014 ، عندما انتقلت إلى قسم التكنولوجيا وعمليات التطوير ، عاش تطوير المنتج بروح الشركة الناشئة: كل شيء يجب القيام به هنا والآن ، لم يتم قبول الخطط طويلة الأجل ، كان هناك الكثير من "الإرث". كان هناك أربعة مهندسين آنذاك ، وكان لدينا العديد من المهام التقنية: كنا بحاجة ماسة للقيام CI ، وتوسيع خط التجميع ، قبل ذلك ، بالطبع ، إنشاء هذا الخط ، وكذلك بناء التفاعل مع عملائنا الداخليين - المبرمجين من أقسام التطوير.ومع ذلك ، مع مرور الوقت ، تحسنت العمليات ، نما القسم. ومعه ، كان هناك فهم متزايد لما أراد مهندسونا معرفته: ما هي آفاق تطويرهم كمتخصصين ، ما الذي يمكن أن يقدمه القسم للمهندسين الجدد؟ أول ما يتبع منطقيًا هو أننا سنحتاج إلى جدول نمو لمواقع وفئات المهندسين. كما يقول المثل: عندما لا يكون لدى المجتمع اختلاف في لون البنطال ، فلا يوجد هدف! وعندما لا يكون هناك هدف ...لقد جعلنا كل شيء بسيطًا قدر الإمكان. يتكون الهيكل التنظيمي الداخلي لقسمنا من ثلاث مناصب قيادية (رئيس القسم ، نائب القائد وقادة المجموعة) وأربعة مناصب تنفيذية (صغار ، عاديون ، كبار وكبار مهندسي البرمجيات) ، والتي تنقسم بدورها إلى ثلاث فئات لكل منها. غالبًا ما يستخدم قسم الموارد البشرية المسمى الوظيفي المماثل ، ولكن بدون تقسيم إلى فئات. بالنسبة إلى قسمنا ، ساعدت الفئات على ضمان نمو أكثر سلاسة وتدريجيًا للموظفين مع زيادة مجالات مسؤوليتهم وعبء العمل.
لكل فئة ، قمنا بتطوير وثائق مع توصيف وظيفي ، حيث تم تحديد وظائف وأدوار الموظفين ، وكذلك تم توضيح مجالات مسؤولية الموظفين عن الخدمات ومجالات العمل.ولكن نظرًا لأننا ، بالإضافة إلى الهندسة ، نحب أيضًا البرمجة ، ولا يحب أي منا قراءة المستندات المملة ، فقد قمنا أيضًا بتبسيط حياتنا قليلاً. لم نكتب كل تعليمات في Word ، ولكن في شكل نص عادي منسق بلغة ترميز Markdown خاصة . في الوقت نفسه ، لا تضيع قراءتها من قبل شخص في أي محرر. بعد ذلك ، قمنا بحفظ هذه النصوص في مستودع GitLab الخاص بنا. يمكن لـ GitLab نفسها عرض تنسيقات المستندات المختلفة بشكل جميل للغاية ، بما في ذلك رسومات Markdown بحيث لا يمكن تمييزها عن Word. ولدى عميل Git القياسي العديد من الميزات الإضافية ، على سبيل المثال ، يمكنه إظهار الاختلاف (الاختلاف) بين وثيقتين.هذا يبسط إلى حد كبير حياة المهندس الذي يريد معرفة المتطلبات الرسمية التي يحتاج إلى اتباعها من أجل الانتقال إلى الخطوة التالية (فئة) من النمو الشخصي في قسمنا. لمعرفة الفرق بين المتطلبات الرسمية لوصف الوظيفة ، تحتاج إلى تنفيذ بعض الخطوات البسيطة: تنزيل المستودع بأوصاف الوظائف من GitLab ، والعثور على المستندات ، وتنفيذ الأمر Git في وحدة التحكم لعرض مقارنة بين الملفين. على سبيل المثال ، يمكنك رؤية الفرق بين مهندس كبير من الفئتين الثانية والأولى كما يلي:git --no-pager diff --no-index
level_08__DevOps_Senior_Software_Engineer_2nd_category.md
level_09__DevOps_Senior_Software_Engineer_1st_category.md
في وحدة التحكم ، التي اعتاد عليها جميع مهندسي البرمجيات ، تبرز علامة الطرح واللون الأحمر للمتطلبات التي تم تغييرها أو تم حذفها ، وتتميز الخطوط المضافة بعلامة زائد ولون أخضر: كل سطر زائد زائد واحد جديد.نعم ، نحن مهووسون بالتقنيات الصغيرة ، ولكن بعد ذلك بدا لنا حلًا رائعًا:
خريطة كفاءة مهندس DevOps
مع تطور قسمنا وزيادة عدد ناقلات المنتجات المدعومة من قبلنا ، أدركنا أنه بالنسبة لكل مجال من مجالات العمل التي نشارك فيها ، لن يكون من الممكن وصف دور فريد وإيجاد مهندس مناسب في السوق. لدينا تفاصيل العمل الخاصة بنا ، على سبيل المثال ، لا نحتاج إلى مطور برامج مبرمج مهاري كبير لحل مشكلات CI ، ولكن مع ذلك ، يجب أن يكون مهندس CI قادرًا على برمجة وحدات ونصوص صغيرة في Python بمستوى مقبول. وبالمثل ، لا نحتاج إلى مسؤول لينكس مؤهل ، ولكننا بحاجة إلى شخص لديه معرفة كافية بنظام التشغيل Debian أو Ubuntu حتى يتمكن من تثبيت وكلاء بناء GitLab CI ، والأفضل من ذلك ، أتمتة هذه الأعمال من خلال SaltStack أو Ansible أو أدوات أخرى.إذن ما الذي يجب على مهندس DevOps الذي يعمل في قسمنا القيام به؟ للقيام بذلك ، تحتاج أولاً إلى تحديد المعرفة والمهارات والقدرات (مختصر ZUN ) بالمعنى العام.- المعرفة هي القوانين الرئيسية لمجال الموضوع ، مما يسمح للشخص بحل مشاكل إنتاجية محددة ومشكلات علمية وغيرها ، أي الحقائق والمفاهيم والأحكام والصور والعلاقات والتقديرات والقواعد والخوارزميات والاستدلال ، بالإضافة إلى استراتيجيات صنع القرار في هذا المجال. المعرفة هي أيضًا عناصر معلومات مرتبطة ببعضها البعض ومع العالم الخارجي.
- المهارات - يُفهم أنهم يتقنون من قبل شخص كيفية القيام بعمل ما ، مع توفير قدر معين من المعرفة. يتم التعبير عن القدرة في القدرة على تطبيق المعرفة بوعي في الممارسة.
- — , . , , , , .
إذا حددنا ZUN بشكل أكثر تحديدًا فيما يتعلق بالمنتجات المطورة في الشركة ، فسوف نحصل على قائمة عامة بالكفاءات. بدون إتقان هذه الكفاءات ، لن يتمكن المهندس من العمل النوعي في قسمنا. تبين أن القائمة طويلة جدًا ، لأنها تأخذ في الاعتبار تفاصيل العمل فورًا في جميع المجالات والتقنيات والمنتجات.وبالتالي ، فقد توصلنا إلى الحاجة إلى وصف وتصنيف جميع متطلباتنا لمهندس في شكل جدولي ، ولدينا " خريطة كفاءة DevOps Engineers 1.0 ". يبدو أن هذا: الجدول مقسم إلى أربعة أقسام كبيرة:
- وصف الكفاءات العامة لموظفي قسم DevOps ، وهو ضروري للحل الناجح للمهام اليومية.
- المعرفة هي المعرفة المحددة والموجهة للمنتج لمهندسي DevOps.
- — ; .
- — ; , .
في خلايا الجدول ، يشار إلى التقييمات النوعية: على أي مستوى يجب أن يتمتع المهندس بكفاءة واحدة أو أخرى. لسوء الحظ ، لا يمكنني تخيل النسخة الكاملة من الجدول هنا ، ولكن هذا ليس ضروريًا ، حيث يجب على كل شركة وكل قسم إنشاء جدول مشابه خاص به ، مع مراعاة تفاصيل العمل.في عام 2018 ، قمت أنا وزملائي بتطوير وإنشاء ما يسمى بالخريطة التكنولوجية لعملية الإنتاج (اقرأ مقالة " إدارة الفوضى: هبر : نرتب الأشياء باستخدام الخريطة التكنولوجية "). بفضلها ، اقتربنا من تشكيل ناقل نمو وتنمية كفاءات مهندسي DevOps اعتمادًا على المنتج والتقنيات المستخدمة فيه ومراحل ناقل المنتج.
تصف هذه الخريطة جميع المراحل والخطوات التي تشكل الناقل التكنولوجي لإنتاج منتجاتنا. الشيء الرئيسي ، من وجهة نظر المنتج ، هو فهم عدد المهندسين ، وما المؤهلات وما هي الكفاءات التي نحتاجها لضمان التشغيل المستمر لهذا الناقل. والأفضل من ذلك ، تخطيط وتأمين الأشخاص بحيث يمكنهم ، على الرغم من دعم الخدمات الحيوية ، على سبيل المثال ، الذهاب في إجازة بهدوء ، مع العلم أن هناك شخصًا في القسم لديه كفاءات متقاطعة ويمكنه استبدالهم.يجب أن يقودنا هذا معًا إلى "خريطة كفاءة DevOps Engineers 2.0" ، والتي ستصف بوضوح ZUN حسب المنتج والكفاءات اللازمة لأتمتة هذا المنتج. أي أنه يجب أن تظهر بعض ربط المراحل على الخريطة التكنولوجية بخريطة كفاءات المهندسين. في المقالة القادمة سأحاول أن أخبركم بما جاء منها.PS وقد كتب المقال يستند إلى قصة لاجتماع يناير، والتي من الزملاء هايز دعا تتكرم لنا لتبادل الخبرات (يمكنك مشاهدة العرض و النص ).المؤلف : تيمور جيلمولين- نائب. رئيس عمليات التكنولوجيا والتطوير (DevOps) ، التقنيات الإيجابية.