مقابلة مع ألكسندر تيتوف ، أحد أعضاء لجنة البرنامج في
مؤتمر يونيو HighLoad ++ ، وسيتم تخصيص قسم منفصل لـ DevOps.
تحت الخفض حول أي اتجاه تهب "رياح" DevOps ، وما هي جوانب هذا المفهوم التي ستتم مناقشتها في المنتدى.
ألكسندر مألوف تمامًا لمجتمعنا ، وهو منظم DevOps Moscow ومؤتمر DevOpsDays Moscow ، وقد كان يتحدث في مناسباتنا منذ عدة سنوات ويساعد في تشكيل برامجهم. وهو حاليًا شريك إداري في Express 42 ، الذي يطور DevOps في شركات التكنولوجيا. في وقت سابق ، من 2010 إلى 2012 ، مر ألكسندر بمسار استحواذ رائع مع Qik ، من تشغيل شركة ناشئة سريعة النمو إلى العمل في شركة دولية كبيرة Microsoft. قبل ذلك ، في 2009-2010 ، كان المدير الفني لأول استضافة سحابية في روسيا ، Skalaxi.- لنبدأ من بعيد: هل تتطور ثقافة DevOps؟ ما التغييرات التي لوحظت في هذا المجال في السنوات الأخيرة؟ وكيف يبدو DevOps في روسيا؟بالطبع ، في عالم حيث تتغير التكنولوجيا بعضها البعض كل ثلاث سنوات ، كل شيء يتغير باستمرار وبشكل كبير. في البداية ، كانت المشكلة الأساسية هي إنتاج وتشغيل البرامج نفسها في العصر الرقمي. حول هذه المشكلة ، اجتمعت حركة DevOps. الآن تم تقسيم المشكلة الأساسية إلى العديد من الفئات الفرعية - إدارة البنية التحتية ، والمراقبة ، والتكامل المستمر ، والتسليم المستمر ، والعمل مع الناس (على وجه الخصوص ، مشكلة الإرهاق للأشخاص الذين يشاركون في كل من الاستغلال والتطوير) ، وبعض الأشياء التكنولوجية (على سبيل المثال ، ظهور Kubernetes ، مثل مثل هذا المعيار الفعلي لمنصة البنية التحتية بالكامل في الشركات). هذا ، في نواح كثيرة ، ظهرت التفاصيل: لقد مررنا بمرحلة فهم ما يجب القيام به بشكل مختلف كما كان من قبل ، وجربنا العديد من الأساليب الجديدة وتوصلنا إلى تشكيل بعض العمليات الموحدة لحل المشاكل (النموذجية) الشائعة. ولكن في الوقت نفسه ، لا تزال الأدوات والعمليات في العديد من الشركات حول العالم رديئة الجودة أو غير رسمية للغاية.
في السياق الروسي ، هناك مشكلة إضافية هي أننا لا نفهم لماذا كل هذا ضروري. هذا يربك الكثيرين. لدينا تطوير واختبار وتشغيل بشكل منفصل ، ثم تأتي بعض Kubernetes لحل بعض المشاكل ، لكنهم يحاولون تنفيذها دون تغيير العمليات والنهج والكفاءات من الناس. كل شيء ينهار. ولماذا هذه التقنيات الجديدة غير واضحة.
- وما هو سبب هذا التحول الجذري؟كما ذكرت بالفعل ، بدأنا في حل مشكلة أخرى. في البداية ، حلت تكنولوجيا المعلومات الكلاسيكية مشكلة أتمتة العمليات التجارية داخل الشركة. تم تعديل البنية التحتية بالكامل وفقًا لذلك - قواعد البيانات والحافلات وما إلى ذلك. منذ عام 2000 ، بعد أزمة الإنترنت ، تحولت تكنولوجيا المعلومات إلى إنشاء منتجات رقمية يمكنها تقديم خدمات مخصصة بشكل كبير ، وتقديم بعض القيمة. إذا قامت الشركة قبل إنتاج طراز معين من السيارات ، فقد تحولت الآن إلى التخصيص لكل عميل. هذا هو حل لمشكلة أخرى ، والتي تتطلب مناهج وتقنيات مختلفة بشكل أساسي - عملية إنتاج برامج مختلفة. هنا لم يعد من الممكن القيام بالتطوير والاختبار والتشغيل بالتتابع. الآن تبدأ هذه العمليات في وقت واحد.
بالمناسبة ، على الرغم من ذلك ، هناك اعتقاد خاطئ بأن DevOps عن العملية. تتم إعادة تسمية مسؤولي النظام الكلاسيكي الذين يؤدون العمل التشغيلي ببساطة إلى مهندسي DevOps ، مما يسيء إلى المصطلح من حيث المبدأ. في الواقع ، المفهوم أوسع بكثير. هذه مجموعة منفصلة من الممارسات ، إطار منفصل يسمح لك بحل مشاكل معينة في ظروف معينة ومع أشخاص من ذوي كفاءة معينة - لا أكثر ولا أقل. فقط عدد قليل من الناس يفهمون لماذا هذا ضروري. وهذه إحدى المشاكل التي نحاول حلها من خلال المؤتمرات.
-
ما هي التقارير المخططة للتركيز على الأقسام داخل التحميل السيبيري؟إذا كانت هناك تقارير تشغيلية في وقت سابق بشكل أساسي ، فإننا نريد هذا العام إضافة المزيد من المعلومات حول الارتباط بالتطوير ، على سبيل المثال ، حول عمليات التسليم المستمر ، والتكامل المستمر ، والاختبار. مثال رائع هو تقرير من Maxim Lapshin على RIT ++ (كجزء من Spring RootConf 2018) حول كيفية استخدام DevOps في تطوير الصندوق. مثل هذه الشركة ليس لديها أي استغلال - فهي تصنع صندوقًا تبيعه للعميل. في الوقت نفسه ، لديها DevOps في الداخل. يكسر هذا النهج النمط ، ولكن في نفس الوقت يساعد على فضح الأسطورة المذكورة أن DevOps هي فقط حول العملية. هذا هو تركيزنا الأساسي الأول.
التركيز الثاني هو التقنيات الجديدة. الآن من المألوف الحديث عن Kubernetes و Prometheus وغيرهم. ونحن نبحث عن أشخاص تمكنوا من الشعور بهذه التقنيات في الممارسة العملية. لم يتم تكوينها وجعلها تعمل فحسب ، بل تم تضمينها أيضًا في عملية تطويرها. بشكل عام ، نحاول النظر في جميع التقنيات من منظور كيف يتم تضمينها في عملية إنتاج البرامج - ما هي المشكلة التي يحلونها ، والأهداف التي يتم تعيينها ، وما إلى ذلك. إذا كنت لا تتحدث عن هذا ، فسيبدأ الناس في العمل مع التكنولوجيا كعبادة شحن: "لنضع Kubernetes قيد التشغيل ويمكننا إنشاء Google". لن يعمل بهذه الطريقة.
- إن مفهوم التكامل المستمر مقبول بالفعل من قبل السوق. بالإضافة إلى أدوات محددة ، هل هناك شيء نتحدث عنه؟بالطبع. المفهوم الأساسي ، حتى يمكن للمرء أن يقول ، هو أنه في سياق DevOps ، لا يتم اختبار المنتجات للجودة داخل عملية التكامل المستمر. أي أنه لا يهم مدى نضج المنتج من الناحية الوظيفية. من المهم التحقق من مدى نجاحه وما إذا كان جاهزًا للتكامل مع المكونات الأخرى.
يعد هذا تغييرًا كبيرًا ، نظرًا لوجود تكامل مستمر في التطوير والتشغيل والاختبار المتناسق. ولكن هناك ، على هذا المستوى ، يتم التحقق من جودة المنتج وفقًا لمتطلبات المستخدم ، وفي إطار DevOps ، يتم فحص الصفات الوظيفية. هذه المرحلة هي التي تسمح بأسرع تكامل ممكن للخدمات الفردية في إطار البنية التحتية للخدمات الصغيرة (و DevOps ككل لا توجد بدون بنية الخدمات الصغيرة).
- ما هي الأدوات التي يتم التركيز عليها هذا العام؟بادئ ذي بدء ، Kubernetes المذكورة بالفعل. ظهرت منذ بعض الوقت ، لكنها وصلت مؤخرًا إلى المرحلة التي يمكن استخدامها فيها. الآن يمكن استخدامه من قبل أي شركة تقوم بتطوير خدمة رقمية محدثة ، على سبيل المثال ، توفير الخدمات من خلال مواقع الويب أو تطبيقات الهاتف المحمول.
غالبًا ما يشار إليه باسم Prometheus - نظام مراقبة ، GitLab - كنظام تكامل مستمر. وكذلك مجموعة HashiCorp بأكملها - Vault ، Terraform (كلاهما طورتها HashiCorp). حسنًا ، بالطبع ، Docker - كتنسيق تسليم.
- هل هناك تحولات أخيرة في إطار مفهوم "كل شيء كرمز"؟من الواضح أن ممارسة "كل شيء كرمز" مفيدة في حد ذاتها. هذا هو أحد المبادئ الأساسية التي تقوم عليها عملية DevOps. Kubernetes تواصل هذه الإيديولوجية.
في DevOps ، القصة الرئيسية هي "البنية التحتية ككود". وهذا ليس مجرد مفهوم ، بل هو أيضًا عملية يتم فيها عرض جميع المكونات في شكل رمز يسمح لـ "قطع" فردية من البنية التحتية بالتفاعل مع بعضها البعض. لا توجد تغييرات جذرية هنا ، ولكن كممارسة ، فهي تتطور الآن داخل Kubernetes. على سبيل المثال ، يتم تطوير أدوات إدارة التبعية مثل Helm ، وأدوات إنشاء وحدات منفصلة ، ووصف البنية التحتية ، على سبيل المثال ، عوامل التشغيل (وتظهر أطر عمل لكتابة البيانات في Kubernetes) ، إلخ. وبعبارة أخرى ، هناك تطور صحي للأداة واختراق الممارسة داخلها.
- هل ممارسة "كل شيء كرمز" منفصلة عن الصك الذي يستحق الحديث عنه؟لم نقم بعد بتشكيل برنامج بشكل كامل ، لذلك لا يمكنني أن أقول ما إذا كنا سنثير مثل هذه المواضيع بشكل خاص على HighLoad ++. لكن هذا في حد ذاته أمر ممكن.
هناك العديد من الطرق لتنظيم البنية التحتية ، وإدارة التبعية داخل كود البنية التحتية ، واختبارها. بالطبع ، سنتحدث عن مفاهيم للعمل مع الممارسة - على سبيل المثال ، يجب تقسيم رمز البنية التحتية إلى وحدات. يبدو لي أن هذه المواضيع المحسنة ، بمعزل عن الممارسة ، لا تتناسب بشكل جيد للغاية. ولكن ، ربما ، سنختار تقريرًا حيث سيتم جمع كل الأساليب الممكنة في إطار وصف نظام واحد. ومع ذلك ، يكون أكثر قيمة عندما يقول الناس ويظهرون كيف يتم تحقيق هذه المفاهيم النظرية في الواقع. حول النظرية التي تكمن وراء الممارسات ، يمكنك بعد ذلك التحدث مع نفس الأشخاص على الهامش.
- هناك رأي مفاده أن شعبية العمارة المدفوعة بالحدث تتزايد بمرور الوقت. هل توافق على هذا البيان؟لطالما كانت البنية التحتية المدفوعة بالحدث جزءًا من نهج الدردشة - فبالنسبة إلى الحدث ، نتخذ قرارًا في الدردشة حول ما يجب أن يحدث لقطعة من البنية التحتية. هذه القصة ضرورية جدًا للشركات الكبيرة الكبيرة ، لكنها لا تزال غير ناضجة تمامًا بالنسبة لبقية الجمهور. من أجل اتخاذ قرارات بشأن ما يجب أن يحدث (ما يجب أن نفعله) ، من الضروري تطوير إطار عمل للقواعد داخل الفرق حول كيفية اتخاذنا لهذه القرارات ، بحيث يفعل الجميع نفس الشيء تقريبًا - انظر من جانب واحد. وبهذا ، كل شيء معقد. إن تنسيق تطوير مثل هذا الإطار هو ما يتحدث عنه الجميع الآن: كيف يمكن جعله آليًا ، ونقله إلى أداة ، وكيف يجب القيام به على مستوى بناء الفريق وكيفية التنسيق مع الفرق المختلفة.
- هل ينعكس هذا بطريقة أو بأخرى في تقارير المؤتمر؟لا ، إن HighLoad ++ يتعلق أكثر بالنظم والأدوات التي يتم تحميلها بكثرة ، لذا يمكننا هنا التحدث عن الأدوات ، ولكن ليس حول تطوير مثل هذا الإطار. ولكن في الخريف سيكون لدينا مؤتمر RootConf منفصل ، والذي سيعقد في 1-2 أكتوبر. حتى عام 2011 ، كان مخصصًا للقضايا التشغيلية (أي مكون واحد فقط من العملية بأكملها "تطوير اختبار - اختبار"). في عام 2015 ، قمنا بتجسيده في سياق DevOps بأكمله - لذلك قمنا بتوسيع الموضوع تدريجيًا. في RootConf ، نناقش كيفية ضمان تفاعل المطورين ومهندسي الصيانة ، نتحدث عن العمليات والتقنيات الجديدة ، عن منصات البنية التحتية وإدارة البنية التحتية ، والتي لا تشارك في نموذج DevOps فقط في التشغيل ، ولكن أيضًا في التطوير (إنهم يقومون بوظائف مختلفة فقط).
- هل كانت هناك تقنيات مثيرة للاهتمام لتحسين مرونة المشاريع في العامين الماضيين؟ هل سيتم مناقشتها في المؤتمر؟اليوم صادفنا مفارقة تتعلق بحقيقة أن "التسامح مع الخطأ" لا يعني "الموثوقية". تحل الموثوقية الآن محل التسامح مع الخطأ.
تحمل الخطأ هو مفهوم من نموذج الأنظمة المتجانسة ، حيث تم حل مشكلة الموثوقية من خلال الازدواجية ، وزيادة الموارد ، إلخ. الآن هذه الأساليب لم تعد تعمل. تعتمد الموثوقية على مقاربات مختلفة اختلافًا جوهريًا - فهي تعني "مقاومة هشاشة" النظام. أي أن النظام يصبح "ضعيفًا": إذا تصرفنا بناءً عليه ، فإنه يتغير ، ولا ينهار. بمعنى آخر ، إذا كنت ستنشئ نوعًا من الخدمة الجديدة ، فيجب عليك توفير مثل هذه المتغيرات لسلوكها ، حيث إذا حاول المستخدم أو البيئة التي يعمل فيها تدميرها ، فإن الخدمة ببساطة تغير خصائصها ، بينما لا تزال الخدمة متوفرة ، يتم إعطاء بعض النتائج.
من العلامات الجيدة على هذا الاتجاه هو ظهور هندسة موثوقية الموقع كممارس ومتخصص فردي - مهندس موثوقية الموقع (SRE) كبديل للكفاءة السابقة لمسؤول النظام. كتوضيح لهذه العملية ، سأذكر أن Google أصدرت ممارساتها في تنفيذ DevOps في شكل كتاب عن هندسة موثوقية الموقع وهي تروج بنشاط لهذه الفكرة للجماهير.
سنتحدث أيضًا عن هذا في RootConf. الآن هذا الموضوع قيد الضجيج في الغرب ، ونحن (بواسطة مجتمع DevOps موسكو) نحاول تقديمه لنا تدريجيًا.