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