"إنشاء تكنولوجيات دون التفكير في من يستخدمها" لا معنى له على الإطلاق ": مقابلة كبيرة مع أنتون فايس

إن هذا habrapost هو مقابلة مع Anton Weiss ، المالك المشارك للاستشارات التكنولوجية Otomato Software ، صاحب أكثر من 15 عامًا من الخبرة في مجال التكنولوجيا المتقدمة. وهو خبير في التدريس الفني ، وهو البادئ والمؤلف المشارك في أول دورة لإصدار شهادات DevOps الإسرائيلية. يشارك أنطون في المؤتمرات الدولية ويعرف باسم المتحدث الرائع.

سنتحدث عن المواضيع التالية:

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

الفرق بين روسيا وإسرائيل

أوليغ: من فضلك قل لي من أنت وماذا تفعل.

أنتون: أنا أنتون ، لقد ولدت في سان بطرسبرغ ، لكنني انتقلت إلى إسرائيل في سن الخامسة عشر وأعيش هناك منذ ذلك الحين. على مدار العشرين عامًا الماضية في إسرائيل ، شاركت في تكنولوجيا المعلومات بأشكالها المختلفة. من هذه السنوات العشرين ، تخصصت العشر سنوات الأخيرة في كل ما يتعلق بتسليم البرامج: التكامل ، ما كان يسمى إدارة التكوين ، وما يسمى الآن DevOps. عملت في شركات كبيرة - في شركات دولية مثل AT&T و BMC. كان يعمل في الشركات الناشئة. على مدار الأعوام الأربعة الماضية ، كان لديّ شركتي الاستشارية الخاصة ، التي تسمى Otomato Software ، حيث نلتزم بمساعدة المؤسسات على تحسين عمليات التسليم وإتقان الأدوات الجديدة: أي أننا نقوم بالجزء الفني وكل شيء موجود.

أوليغ: هل هناك فرق بين روسيا وإسرائيل فيما يتعلق بالعمل؟

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

- حسنا كيف؟

- حسنا اذن. يقولون إنه من الصعب القيام بذلك ، والآن بدأ شيء ما يحدث.

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

الفرق بين الشركات الناشئة والعمالقة

أوليغ: فهمت ذلك. بالمناسبة ، أين هو أكثر إثارة للاهتمام وممتعة بالنسبة لك للعمل: في الشركات الناشئة أو في المؤسسات الكبيرة؟

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

أوليغ: وماذا عن الاختلاف في نهج DevOps في الشركات الصغيرة والكبيرة؟ وهذا هو ، إذا كنت ، على سبيل المثال ، تعمل لشخصين ، لا يمكنك تكوين CI / CD الخاص بك ، ولكن نسخ الأعمال الفنية من SCP.

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

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

الاتجاه هو زيادة التعقيد ، وماذا تفعل حيال ذلك

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

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

أوليغ: هل كان ذلك قبل عام؟

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

أوليغ: وما هو الجواب؟ كيفية إدارة هذا التعقيد؟

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

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

سحابة الأم

أوليغ: هل يمكنك أن تشرح قليلاً ما هي خدمة Cloud Native؟ نظرًا لأنه أصبح نوعًا من الكلمات الطنانة ، فالجميع يكتبه الآن على كل جدار. كيف ترى ذلك؟

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

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

ولكن لسبب ما ، لم يبرر نهج "المنصة كخدمة" هذا نفسه ، ولم يحدث الازدهار الموعود. هذا هو ، نعم ، لقد كان Heroku ، وبعدها مباشرة رفع جميع اللاعبين الكبار نظائرهم: Google App Engine ، Amazon - Elastic Beanstalk. كان علي أن أعمل كثيرًا مع الشركات التي بدأت بهذا. ولكن في الوقت الذي تقوم فيه بعمل ما يتجاوز قليلاً الحدود المسموح بها من قبل النظام الأساسي ، يتحول إلى صداع رهيب. لأنك تبدأ في عبور الجدران الموجودة في كل مكان. وبينما يميل الناس إلى ذلك ، عندما يتعثرون على الجدران ، يبدأون في البحث عن وسيلة لاختراق الجدار.

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

أوليغ: ربما ، على المنظمة نفسها أن تتعلم بطريقة أو بأخرى أن تعيش مع كل هذه الأشياء.

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

الجمع بين المهارات الفنية وغير الفنية

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

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

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

كيف لمعرفة بسرعة DevOps

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

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

الآن يقال الكثير عن المهنيين في شكل "T". يجب أن تفهم مكان تواجدك على الأقدام ، اختر شيئًا واحدًا ، وابدأ في الحفر في هذا المكان. سيتم العثور على أعماق هائلة في وقت الحفر. ولكن يمكنك الحفر في أي مكان. وأنا أدرك جيدًا أن هناك العديد من المناطق التي لم أحفرها بعمق ، لأنني حاولت أن ننظر وأدركت أنها ليست لي. وهنا ، حيث تهتم بالحفر - استمر في الحفر ، ومن المهم جدًا التحدث عن ذلك. هذا ، مرة أخرى ، أفهم أن هذا ليس للجميع. : -, , , — , Gist' GitHub. - — .

. DevOps — . , , . , , , , - , - , , - . , . , , , , , , , . , . . ? — , , . , , . , . شيء من هذا القبيل. .

: , , DevOps', , . , , . , -, , … , . - , ? . , , : « ». , ?

: -, , , : « ». - , , , , . , , : « ».

: ?

: , , , , , . , — . , , «, , », - . , - , . - , - . , Agile: , , , , , .

, . . , — , - — , , — , , , , , . : « — , . , , . , . , , , -, , , ». , , , .

, - , , continuous integration … , , , . , , . , 10 : , , - , , , , , , , , . — . : , , , , . E - , , .

: . , - , , - , , , , DevOps -. ?

: , , , , . , , , , ? , , . . - , , .

, , . , , .

DevOps

: , : Google, Netflix, . , ?

: , , ( ) , — , , , . , , lean management — value stream mapping. . , , , - : , , , , , , , , . , , , .

: ? - — - , , — . , , , , . , , , Java, , , . , :

— , .
— , ? ?
— , , .

, , , , — , . — , .

, :
— .

:
— , , . .

, , :
— .

:
— . ?

:
— , .

, — , , . . . , CI/CD — . , . , , . , , .

: , ? , CI/CD . ?

: -, , . - , , , , . Kubernetes: , — Kubernetes. VMware , Kubernetes . , Google . , , .

: Google ?

: , , Swarm Kubernetes, Docker. Docker , . , Microsoft, Amazon — « Docker». Docker! Docker . , , , , Google, Microsoft, Amazon? , . , , , . , . وهذا ما حدث.

لذلك هنا. . — . — « Kubernetes , ». . Kubernetes . Kubernetes — - API, , . API . — , , , , : « API, , Kubernetes, Kubernetes , ».

— , Continuous Delivery Foundation, - , , Google, CloudBees, GitLab. Tekton, — API continuous delivery-. , continuous integration / continuous delivery- Kubernetes, , , . , . Microsoft , , SMI Spec. , , - .

Kubernetes . , , - , , Kubernetes — .

أوليغ: ما هي التقارير التي تذهب إليها أنت بنفسك ، ما الذي تثير اهتمامك؟

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

أوليغ: وما نوع التدريس الفني؟ ماذا تفعل

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

أوليغ: هل تذهب أساسًا إلى تقرير أو موضوع أو شخص؟

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

أوليغ: هل هذا هو الرفيق الذي لديه كتاب متوسط ؟ جعلها في شكل وظائف. تنسيق غير عادي.

انطون: يتحدث حقا رائع جدا. محاضراته على مدى السنوات 2-3 الماضية أتذكر أكثر من غيرها. حسنًا ، جون ويليس ، الذي جاء إلى DevOops العام الماضي - لمجرد أنه يعرف حقًا كيف يعرف ذلك . هناك بعض المشاكل معه ، لأنه يتحدث كثيرًا عن الواقع الأمريكي ، وهي أشياء لا تنطبق في بعض الأحيان على الواقع الروسي أو الإسرائيلي. الآن لديهم نوع من الحرب الآن مع بعض لوحات الموافقة على التغيير ، والتي يتحدثون عنها باستمرار. هذا ، على ما يبدو ، شيء معين موجود في المؤسسات الأمريكية ، فهناك مثل هذه العملية لإجراء التغييرات في تكنولوجيا المعلومات والموافقة عليها ، وهناك حاجة إلى تنفيذ نوع من الالتزامات.

أوليغ: لكن ليس لدينا هذا - حتى أنني لا أفهم ما الذي تتحدث عنه الآن.

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

أوليغ: كنت في DevOops الماضي ، ما هي التقارير التي تستحق الذهاب إلى ومراجعة التسجيلات؟

انطون: انظر الجميع . مهتمة قليلا في الموضوع - الذهاب.

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

أنتون: لا ، لا تذهب إليه ، بعض الأشياء المملة :-)

أوليغ: حسنًا ، شكرًا جزيلًا. كان ذلك رائعا! أرى أنك قدمت بالفعل تقريرًا إلى المؤتمر التالي ، لذا - أراك في DevOops التالي!

سيعقد مؤتمر DevOops 2020 في موسكو يومي 29 و 30 أبريل ، وهذه المرة في موسكو. وصفنا جوهر المؤتمر حول حبري في إعلان "DevOps- المهندسين غير موجودون" . يتم تشكيل البرنامج بنشاط (لا يزال هناك عدة أشهر قبل المؤتمر) ، ولكن يمكن بالفعل مشاهدة المتحدثين الأوائل على الموقع . يمكنك شراء التذاكر هناك .