في الآونة الأخيرة، غمرت هذه الإعلانات شبكة الإنترنت. على الرغم من الراتب اللطيف، لا يسع المرء إلا أن يشعر بالحرج من أن البدع البرية مكتوبة في الداخل. في البداية، من المفترض أن "DevOps" و"engineer" يمكن لصقهما معًا بطريقة ما في كلمة واحدة، ومن ثم تظهر قائمة عشوائية من المتطلبات، والتي تم نسخ بعضها بوضوح من الوظيفة الشاغرة لمسؤول النظام.
في هذا المنشور، أود أن أتحدث قليلاً عن كيفية وصولنا إلى هذه المرحلة من الحياة، وما هو DevOps حقًا وما يجب فعله به الآن.
يمكن إدانة مثل هذه الوظائف الشاغرة بكل الطرق، ولكن تظل الحقيقة: هناك الكثير منها، وهذه هي الطريقة التي يعمل بها السوق في الوقت الحالي. لقد عقدنا مؤتمر المطورين ونعلن صراحة: " - ليس لمهندسي DevOps." سيبدو هذا غريبًا وغريبًا بالنسبة للكثيرين: لماذا يتعارض الأشخاص الذين يقومون بحدث تجاري بالكامل مع السوق. الآن سنشرح كل شيء.
حول الثقافة والعمليات
لنبدأ بحقيقة أن DevOps ليس تخصصًا هندسيًا. بدأ كل شيء بحقيقة أن تقسيم الأدوار الراسخ تاريخياً لا يتناسب مع جودة المنتجات. عندما يقوم المبرمجون بالبرمجة فقط، ولكنهم لا يريدون سماع أي شيء عن الاختبار، فإن البرنامج مليء بالأخطاء. عندما لا يهتم المسؤولون بكيفية أو سبب كتابة البرنامج، يتحول الدعم إلى جحيم.
على سبيل المثال، وصف الفرق بين مسؤول النظام ونهج SRE لإدارة الخدمة . وقد تم إجراء دراسات مثيرة للاهتمام في الداخل - من الواضح أن أفضل المطورين تمكنوا بطريقة ما من نشر تغييرات جديدة على الإنتاج بشكل أسرع من مرة واحدة في الساعة. إنهم يختبرون بأيديهم ما لا يزيد عن 10٪ (وهذا يمكن رؤيته من ). كيف يفعلون هذا؟ "التفوق أو الموت" يقول أحد عناوين التقرير. للحصول على مناقشة مفصلة لهذه الإحصائيات في سياق الاختبار، يمكنك الرجوع إلى الكلمة الرئيسية لباروخ سادوغورسكي في مؤتمرنا الآخر، Heisenbug.
"عندما لا يكون هناك اتفاق بين الرفاق،
لن تسير أعمالهم على ما يرام ،
ولن يخرج منه شيء إلا الطحين.
ذات مرة البجعة وجراد البحر والرمح..."
أي جزء من مبرمجي الويب تعتقد أنه يفهم حقًا الظروف التي يتم بموجبها استخدام تطبيقاتهم في الإنتاج؟ كم منهم سيذهب إلى المسؤولين ويحاول معرفة ما سيحدث إذا تعطلت قاعدة البيانات؟ ومن منهم سيذهب إلى المختبرين ويطلب منهم أن يعلموهم كيفية كتابة الاختبارات بشكل صحيح؟ وهناك أيضًا حراس أمن ومديرو منتجات ومجموعة من الأشخاص الآخرين.
الفكرة العامة لـ DevOps هي خلق تعاون بين الأدوار والأقسام. بادئ ذي بدء، لا يتم تحقيق ذلك من خلال بعض البرامج التي تم تكوينها بذكاء، ولكن من خلال ممارسة الاتصال. تدور أحداث DevOps حول الثقافة والممارسات والمنهجية والعمليات. لا يوجد تخصص هندسي يستطيع الإجابة على هذه الأسئلة.
الحلقة المفرغة
من أين أتى نظام "هندسة التطوير" في ذلك الوقت؟ لدينا نسخة! كانت أفكار DevOps جيدة، وكانت جيدة جدًا لدرجة أنها أصبحت ضحية لنجاحها. بدأ بعض المجندين المشبوهين والمتاجرين بالبشر، الذين لديهم أجواء خاصة بهم، في الدوران حول هذا الموضوع برمته.
تخيل: بالأمس كنت تصنع الشاورما في خيمكي، واليوم أنت بالفعل رجل كبير، أحد كبار المجندين. هناك عملية كاملة للبحث عن المرشحين واختيارهم، كل شيء ليس بالأمر السهل، عليك أن تفهمه. لنفترض أن رئيس القسم يقول: ابحث عن متخصص في X. نخصص كلمة "مهندس" لـ X، وننتهي. هل تحتاج إلى نظام Linux؟ حسنًا، هذا بالتأكيد مهندس Linux، إذا كنت تريد DevOps، فهو مهندس DevOps. لا تتكون الوظيفة الشاغرة من عنوان فحسب، بل يجب أيضًا إدخال بعض النص بداخلها. أسهل طريقة هي إدخال مجموعة من الكلمات الرئيسية من جوجل، حسب خيالك. يتكون DevOps من كلمتين - "Dev" و"Ops"، مما يعني أننا بحاجة إلى لصق الكلمات الرئيسية المتعلقة بالمطورين والمسؤولين معًا، كل ذلك في كومة واحدة. هكذا تظهر الوظائف الشاغرة حول إتقان 42 لغة برمجة و20 عامًا من استخدام Kubernetes وSwarm في وقت واحد. مخطط العمل.
هذه هي الطريقة التي ترسخت بها الصورة التي لا معنى لها والتي لا ترحم لبطل خارق معين "devops" في أذهان الناس، والذي سيقوم بتكوين الجميع للانتشار في Jenkins، وستأتي السعادة. أوه، لو كان كل شيء بهذه البساطة. "وهذه أيضًا هي الطريقة التي يمكنك بها مطاردة مسؤولي النظام،" كما يعتقد قسم الموارد البشرية، "إنها كلمة عصرية، والكلمات الرئيسية هي نفسها، ويجب أن يبتلعوا الطعم".
الطلب يخلق العرض، وقد امتلأت كل هذه الوظائف الشاغرة بعدد هائل من مسؤولي النظام الذين أدركوا: يمكنك القيام بكل شيء كما كان من قبل، ولكن يمكنك الحصول على المزيد عدة مرات من خلال تسمية نفسك بـ "devops". تمامًا كما قمت بتكوين الخوادم عبر SSH يدويًا واحدًا تلو الآخر، ستستمر في تكوينها، ولكن من المفترض الآن أن هذه ممارسة للمطورين. هذه ظاهرة معقدة نوعًا ما، وترتبط جزئيًا بالتقليل من شأن المسؤولين الكلاسيكيين والضجيج المحيط بـ DevOps، ولكن بشكل عام، حدث ما حدث.
لذلك لدينا العرض والطلب. حلقة مفرغة تغذي نفسها. وهذا ما نحاربه (بما في ذلك إنشاء مؤتمر DevOops).
بالطبع، بالإضافة إلى مسؤولي النظام الذين أعادوا تسمية أنفسهم "devops"، هناك مشاركين آخرين - على سبيل المثال، SREs المحترفين أو مطوري البنية التحتية كرمز.
ما يفعله الأشخاص في DevOps (حقًا)
لذلك تريد المضي قدمًا في تعلم ممارسات DevOps وتطبيقها. ولكن كيف نفعل هذا، في أي اتجاه للنظر؟ من الواضح أنه لا يجب عليك الاعتماد بشكل أعمى على الكلمات الرئيسية الشائعة.
إذا كان هناك عمل، يجب أن يقوم به شخص ما. لقد اكتشفنا بالفعل أن هؤلاء ليسوا "مهندسين مطورين"، فمن هم إذن؟ يبدو من الأصح صياغة ذلك ليس من حيث المواقف، ولكن من حيث مجالات العمل المحددة.
أولاً، يمكنك معالجة قلب DevOps، أي العمليات والثقافة. الثقافة عمل بطيء وصعب، وعلى الرغم من أنها تقليديًا مسؤولية المديرين، إلا أن الجميع يشاركون فيها بطريقة أو بأخرى، من المبرمجين إلى الإداريين. قبل شهرين تيم ليستر :
"يتم تحديد الثقافة من خلال القيم الأساسية للمنظمة. عادة لا يلاحظ الناس هذا، ولكن بعد أن عملنا في مجال الاستشارات لسنوات عديدة، اعتدنا على ملاحظة ذلك. تدخل شركة وفي غضون دقائق قليلة تبدأ في الشعور بما يحدث. نحن نسمي هذا "النكهة". في بعض الأحيان تكون هذه الرائحة جيدة حقًا. في بعض الأحيان يسبب الغثيان. (...) لا يمكنك تغيير ثقافة ما حتى يتم فهم القيم والمعتقدات الكامنة وراء أفعال محددة. من السهل ملاحظة السلوك، لكن البحث عن المعتقدات أمر صعب. إن DevOps هو مجرد مثال رائع لكيفية تزايد تعقيد الأمور."
هناك أيضًا جزء تقني من المشكلة بالطبع. إذا تم اختبار الكود الجديد الخاص بك خلال شهر واحد، ولكن تم إصداره بعد عام واحد فقط، وكان من المستحيل فعليًا تسريعه بالكامل، فقد لا تلتزم بالممارسات الجيدة. الممارسات الجيدة مدعومة بأدوات جيدة. على سبيل المثال، مع وضع فكرة البنية التحتية كرمز في الاعتبار، يمكنك استخدام أي شيء بدءًا من AWS CloudFormation وTerraform وحتى Chef-Ansible-Puppet. عليك أن تعرف وأن تكون قادرًا على القيام بكل هذا، وهذا بالفعل تخصص هندسي تمامًا. من المهم عدم الخلط بين السبب والنتيجة: فأنت تعمل أولاً وفقًا لمبادئ SRE وبعد ذلك فقط تنفذ هذه المبادئ في شكل بعض الحلول التقنية المحددة. وفي الوقت نفسه، تعد SRE منهجية شاملة للغاية لا تخبرك بكيفية إعداد Jenkins، بل تخبرك بخمسة مبادئ أساسية:
- تحسين التواصل بين الأدوار والإدارات
- قبول الأخطاء كجزء لا يتجزأ من العمل
- إجراء التغييرات تدريجيا
- استخدام الأدوات والأتمتة الأخرى
- قياس كل ما يمكن قياسه
هذه ليست مجرد مجموعة من البيانات، ولكن محددة . على سبيل المثال، في طريق قبول الأخطاء، ستحتاج إلى فهم المخاطر وقياس مدى توفر الخدمات وعدم توفرها باستخدام شيء مثل SLI () و سلو () ، تعلم كيفية كتابة تشريح الجثة وجعل كتابتها غير مخيفة.
في تخصص SRE، يعد استخدام الأدوات جزءًا واحدًا فقط من النجاح، على الرغم من أهميته. نحن بحاجة إلى التطوير المستمر من الناحية الفنية، والنظر إلى ما يحدث في العالم وكيف يمكن تطبيقه في عملنا.
وفي المقابل، أصبحت حلول Cloud Native الآن شائعة جدًا. وكما هو محدد من قبل مؤسسة Cloud Native Computing Foundation اليوم، فإن تقنيات Cloud Native تمكن المؤسسات من تطوير وتشغيل تطبيقات قابلة للتطوير في البيئات الديناميكية الحالية، مثل السحابة العامة والخاصة والهجينة. تشمل الأمثلة الحاويات وشبكات الخدمة والخدمات الصغيرة والبنية التحتية غير القابلة للتغيير وواجهات برمجة التطبيقات التعريفية. تسمح كل هذه التقنيات للأنظمة المترابطة بشكل غير محكم بالبقاء مرنة، ويمكن التحكم فيها، ويمكن ملاحظتها بدرجة كبيرة. تسمح الأتمتة الجيدة للمهندسين بإجراء تغييرات كبيرة بشكل متكرر وبنتائج يمكن التنبؤ بها دون جعلها عملاً روتينيًا. كل هذا مدعوم بمجموعة من الأدوات المعروفة مثل Docker وKubernetes.
يرجع هذا التعريف المعقد والواسع إلى حد ما إلى حقيقة أن المنطقة معقدة للغاية أيضًا. فمن ناحية، يقال إنه ينبغي إضافة تغييرات جديدة على هذا النظام بكل بساطة. من ناحية أخرى، لمعرفة كيفية إنشاء نوع من البيئة الحاوية التي تعيش فيها الخدمات المترابطة بشكل غير محكم على بنية تحتية معرفة برمجيًا ويتم تسليمها هناك باستخدام CI/CD المستمر، وبناء ممارسات DevOps حول كل هذا - كل هذا يتطلب المزيد من أكل الكلب.
ماذا تفعل مع كل هذا
كل شخص يحل هذه المشاكل بطريقته الخاصة: على سبيل المثال، يمكنك نشر الوظائف الشاغرة العادية لكسر الحلقة المفرغة. يمكنك معرفة معنى كلمات مثل DevOps وCloud Native واستخدامها بشكل صحيح وفي صلب الموضوع. يمكنك التطوير في DevOps وإظهار الأساليب الصحيحة من خلال المثال الخاص بك.
نحن نقوم بعقد مؤتمر ، مما يوفر فرصة للتعمق أكثر في الأشياء التي تحدثنا عنها للتو. هناك عدة مجموعات من التقارير لهذا:
- العمليات والثقافة.
- هندسة موثوقية الموقع؛
- السحابة الأصلية؛
كيف تختار أين تذهب؟ هناك نقطة خفية هنا. من ناحية، يتعلق DevOps بالتفاعل، ونريدك حقًا أن تحضر العروض التقديمية من كتل مختلفة. من ناحية أخرى، إذا كنت مدير التطوير الذي جاء إلى المؤتمر للتركيز على مهمة واحدة محددة، فلن يحدك أحد - من الواضح أن هذا سيكون كتلة حول العمليات والثقافة. لا تنس أنه سيكون لديك تسجيلات بعد المؤتمر (بعد ملء نموذج الملاحظات)، حتى تتمكن دائمًا من مشاهدة العروض التقديمية الأقل أهمية لاحقًا.
من الواضح أنه في المؤتمر نفسه، لا يمكنك الانتقال إلى ثلاثة مسارات في وقت واحد، لذلك نقوم بتنظيم البرنامج بحيث تحتوي كل فتحة زمنية على موضوعات تناسب كل الأذواق.
كل ما تبقى هو أن تفهم ما يجب عليك فعله إذا كنت مهندس DevOps! أولاً، حاول تحديد ما تفعله بالفعل. عادة ما يحبون تسمية هذه الكلمة:
- المطورين الذين يعملون على البنية التحتية. مجموعات التقارير حول SRE وCloud Native هي الأكثر ملاءمة لك.
- مسؤولي النظام. الأمر أكثر تعقيدًا هنا. DevOops لا يتعلق بإدارة النظام. لحسن الحظ، هناك الكثير من المؤتمرات والكتب والمقالات ومقاطع الفيديو الممتازة على الإنترنت وما إلى ذلك حول موضوع إدارة النظام. ومن ناحية أخرى، إذا كنت مهتمًا بتطوير نفسك من حيث فهم الثقافة والعمليات والتعرف على التقنيات السحابية وتفاصيل الحياة مع Cloud Native، فنحن نحب رؤيتك! فكر في هذا: أنت تقوم بالإدارة، وبعد ذلك ماذا ستفعل؟ لكي تتجنب أن تجد نفسك فجأة في موقف غير سار، عليك أن تتعلم الآن.
هناك خيار آخر: أنت تصر وتستمر في الادعاء بأنك كذلك على وجه التحديد مهندس DevOps ولا شيء آخر مهما كان معنى ذلك. إذًا علينا أن نخيب ظنك، DevOops ليس مؤتمرًا لمهندسي DevOps!
الشريحة من في ميونيخ
سيتم عقد DevOops 2020 موسكو في الفترة من 29 إلى 30 أبريل في موسكو، والتذاكر متاحة بالفعل .
بدلا من ذلك ، يمكنك حتى 8 فبراير. يرجى ملاحظة أنه عند ملء النموذج يجب عليك تحديد الجمهور المستهدف الذي سيستفيد أكثر من تقريرك (هناك مفاجأة مدفونة داخل القائمة).
المصدر: www.habr.com