من مسؤول النظام إلى الشخص

لدى DevOps مشاهدتان راسختان على الأقل - من جانب مسؤولي النظام ومن جانب المطورين. عادة ما يفتخر السابق بأنهم كانوا يستخدمون الشيف / العرائس / Ansible / Docker منذ 200X ، ويعتقد الآخرون أن DevOps إما أن يتجاوز عمره ويؤدي إلى NoOps ، أو "لقد لفت كل شيء في حاوية ، ثم كيف تسير الأمور."

في الوقت نفسه ، يقرأ العمل عن DevOps في المقالات ويأمل أن يكتشف الرجال أدناه ما يجب فعله به. في الوقت نفسه ، لا يحدث DevOps نفسه ، ولا يبدو العمل مثل Google ، ولا تصبح الشركة فيروزي ، ولا يبتكر الناس أساليب جديدة لاختبار الفرضيات في العالم.

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

تستند المادة إلى نص تقرير ألكسندر أوزمينوج تيتوف من مؤتمر DevOops لشهر أكتوبر 2017.



بالنسبة لأولئك الذين اعتادوا على مشاهدة التقارير من المؤتمرات في التسجيلات ، نرفق فيديو.



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

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

ثم عملت في شركة Qik ناشئة من سيليكون فالي ، التي كان مكتب تطويرها هنا في روسيا. في Qik ، شعرت حقًا بفائدة مفهوم DevOps ، لأننا في غضون شهرين صنعنا منتجًا نما من 0 إلى 5 مليون مستخدم. إذا كنت في Oversan-Skalaxi ، من وجهة نظر الخدمة ، شعرت أن هناك حاجة إلى DevOps ويحتاج الناس إلى فهم ما هو DevOps لاستخدام الاستضافة السحابية ، ثم في Qik شعرت بذلك كمسؤول عن النظام وكرئيس لقسم إدارة النظام. ثم تم شراؤها بواسطة Skype ، وبدأنا في الاندماج هناك ، ودمج التطورات أيضًا في مجال DevOps هناك ، لأنه لم يكن في Skype. ثم اشترت سكايب مايكروسوفت. يبدو أنه أتى إلى شركة يعمل بها حوالي 40 شخصًا ، وبعد بضع سنوات تعمل في شركة كبيرة بها 100 ألف موظف. لقد كانت تجربة مثيرة جدا للاهتمام.

ونتيجة لذلك ، لم أجد إلى أين أتقدم أكثر في هذه الشركات ، وزملائي وافتتحوا Express 42 ، الذي ينقل DevOps إلى الجماهير. نشأت هذه الفكرة في Oversan-Skalaksi ، وهي تدفعني. من بين أمور أخرى ، أنا متأصل للغاية لمجتمع DevOps في روسيا. أنا منظم اجتماعات DevOpsDays Moscow و Moscow DevOps.

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

كيف تظهر DevOps في الشركة؟

مطور DevOps

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

لقد رأيت الكثير من هذه الشركات. جئت إليهم - لديهم أربعة أقسام تنمية. كل قسم يكتب خدماته الصغيرة الخاصة به ، كل قسم لديه قاعدة بيانات خاصة به. شخص ما Redis ، شخص PostgreSQL ، شخص PostgreSQL و MySQL في نفس الوقت. ويرافقون ذلك ، حتى تنمو قواعد البيانات إلى مثل هذه الأحجام التي لم تعد قادرة عليها.

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

مسؤول النظام DevOps

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

عدة مرات صادفت حقيقة أن هؤلاء الأشخاص قاموا ببناء DevOps على FreeBSD. كانت النتيجة نظامًا مغلقًا ، كتبوه هم أنفسهم ، وفهموا فقط كيف يعمل. على الرغم من تجربة مسؤول النظام الخاص بي ، لم أتمكن من معرفة ذلك ، ولكن إذا لم أستطع ، فكيف يجب على المطور فهم كيفية النشر من خلال نظام CI هذا؟ ونتيجة لذلك ، منعت إداريًا استخدام FreeBSD في الشركة ، على الرغم من أنني أحب وأحب النظام نفسه بصدق ، خاصة أنني أحب OpenBSD. ولكن بعد أسبوع ، من بين خوادم Linux ، بدأت خوادم FreeBSD في الظهور مرة أخرى ، مثل agarics fly.

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

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

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

DevOps للأعمال

طريقة أخرى لظهور DevOps هي من جانب الأعمال. ذهب بعض من كبار المديرين لديك إلى مؤتمر أعمال ، على سبيل المثال ، إلى الوادي ، حيث قيل له أنه إذا لم يكن لديك Docker ، وبعض التكامل المستمر (CI) وشيء آخر ، فلا يمكن اعتبارك شركة تكنولوجيا. يقوم المدير بإرجاع وجمع الموظفين وقراءة الكلمات من دفتر الملاحظات: DevOps و Docker و Concourse CI. يبدأ الرجال في الفهم ، ثم تحدث السيناريوهات المختلطة المذكورة أعلاه: DevOps-developer و DevOps-sysadmin ، وكل هذا يؤدي إلى فوضى لا يمكنك تخطيها.

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

من المؤسسة إلى رشيقة

أولاً ، من وجهة نظر الأعمال ، نشهد مثل هذا التحول: نحن نبتعد عن مؤسسة تقوم بتنفيذ مشاريع ضخمة لنقل الأعمال نفسها من النقطة أ إلى النقطة ب (على سبيل المثال ، استراتيجية مدتها خمس سنوات بهدف الاستحواذ على 70٪ من السوق) ...

... وتعال إلى عالم رشيق. ليس الهدف من Agile أن يكون مرنًا ، ولكن هذه النقطة A معروفة و B ليست كذلك. وهذا هو أعمق ما يمكن أن يحدث. لأنه لا نحن ولا العمل معتادين على العمل مع هذا. تخيل أنك لا تعرف ما سيحدث خلال أسبوع أو أسبوعين ، وأن الزعيم جاء إليك وقال: "لذا ، حاول أن تجلب لي شيئًا لا يمكن أن يكون ، اكتب اسمك حتى لا تنسى على عجل" . وأنت لا تعرف ماذا تفعل ، لكن العالم والأعمال أصبحت بهذه الطريقة ، وعليك أن تعتاد عليها. وكل هذه الممارسات ، مثل Agile ، Scrum ، Kanban ، لا تتعلق بكيفية التعايش معها.


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

لا يظهر DevOps لأن أحدكم يجب أن يكون مرتاحًا ، وليس لأنك تحتاج إلى استخدام تقنيات أكثر برودة. NoSQL ليس أكثر برودة من SQL ؛ علاوة على ذلك ، فهو أسوأ بكثير من SQL من قبل الدولة قبل 3-4 سنوات. تم تطوير قواعد بيانات SQL لمدة 20 عامًا ، وقواعد بيانات NoSQL لمدة عام واحد. ونتذكر الحالة المؤسفة لـ MongoDB منذ 4 سنوات ، عندما لم تكن قاعدة بيانات على الإطلاق.


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

تاريخ DevOps

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

في عام 2003 ، أنشأ Ben Trainor في Google فريق SRE. جوجل هي أول شركة رقمية كبرى في العالم. بالفعل في عام 2003 ، واجهوا مشكلة أنه بالطريقة الكلاسيكية التي اعتاد عليها جميع مطوري البرامج ، لا يمكنهم فعل ما يريدون. وقد ابتكروا بتقديم فريق SRE ، ومنذ ذلك الحين طوروا هذه الممارسة.

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

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

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

كيفية تطبيق DevOps؟

عند استخدام DevOps ، من المهم جدًا أن تدرك حقًا أنك تصنع منتجًا رقميًا وأن الوقت اللازم للتسويق (TTM) مهم للشركات.

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

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

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

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

المطور في DevOps

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

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

لدى المطور فكرة عن بنية التطبيق - وهذا أمر مهم للغاية ، لأنه بدون فهم كيفية عمل الهندسة المعمارية ، وما هي الطبقات التكنولوجية وكيف تتفاعل مع بعضها البعض ، فمن المستحيل التفكير في التكامل.

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

مهندس البنية التحتية

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

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

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

فني اختبار

يتغير المختبر أيضًا قليلاً ويصبح تقنيًا يحقق تحسين جودة البرامج ويحول هذه العملية إلى رمز.

مدير تحرير / محطة خدمة

يضع المدير في اعتباره عملية التسليم المستمر للبرامج ، ويدير توقعات الأعمال والقدرات التقنية ، وينتج الإصدارات والإصدارات. إنه ينتج ، لا يخطط ، لأن عملية الانتقال من النقطة A إلى النقطة B ليست خطية ، وفي مثل هذه الظروف لا يمكنه التخطيط.

نتيجة لذلك ، قاموا جميعًا ببناء منصة للبنية التحتية ، وهي أداة للجميع: مهندسي البنية التحتية والمطورين والمختبرين.


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

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

ضمن هذا المخطط ، من الضروري عدم تقسيم المسؤولية ، ولكن المعرفة والخبرة. بعض الناس (مدير الإصدار أو CTO) لديهم المعرفة والخبرة حول كل شيء - لديهم صورة كاملة. البعض الآخر لديه المعرفة والخبرة حول نظام تنسيق الموارد ، والبعض الآخر لديه معرفة بقاعدة البيانات وما إلى ذلك ، وهذه فرق مختلفة ، أشخاص مختلفون يشغلون مكانًا هنا وفي نفس الوقت مسؤولون عن منصة البنية التحتية بأكملها.


في Express 42 ، نسمي هذا التسوية مفهوم التطبيق الأساسي للخدمة. هناك مستوى أساسي معين - مستوى تنسيق (تخصيص) الموارد ومختلف خدمات البنية التحتية ذات المستوى المنخفض. يتمتع مهندسو البنية التحتية بمزيد من المعرفة والخبرة هنا. هناك مستوى خدمة: قواعد بيانات مختلفة ، موازنات الحمل ، المراقبة ، التسجيل ، محركات CI (TeamCity كمحرك أو Jenkins كمحرك). هناك مستوى تطبيق يجمع هذه المستويات معًا من خلال جميع أنواع واجهات برمجة التطبيقات والوظائف وما إلى ذلك. مرة أخرى ، أشير إلى تقرير نيكولاي ريجيكوف ، فقد أظهر تمامًا كيف يعمل كل هذا معًا وكيفية تنفيذ CI على قمة Kubernetes.


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

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

يجب على الشركات التي تمارس DevOps تنظيم منصة داخلها وبعض أنظمة القيم التي تسمح لنا بمناقشة الأفكار التي نبتكرها باستخدام التقنيات التي نستخدمها ومقدار استخدامنا لهذه التقنيات (Kubernetes ، Prometheus ، Docker ، إلخ.) ، من أجل عزف الموسيقى ، وليس كسر الجيتار على رأس أحد الجيران.

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

- , , . 3-4 , , .

, DevOops 2018 : , . 14 , .