اعتاد Docker أن يكون شيئًا رائعًا وشابًا في حد ذاته. ومن ثم ، توقف عامل الرصيف بطريقة أو بأخرى عن كونه مثيرًا للاهتمام: إنه فقط في كل شخص وفي كل شيء. لديها جميع الخدمات الصغيرة ، Kubernetes ، devops - أي شيء. ومع ذلك ، يسحب الناس الحاويات في أفواههم من أي مكان. غالبًا ما لا يعرفون حتى ما بالداخل.
ما هو المثير للاهتمام الآن لمهندسي DevOps؟ وقع فريق الأبطال الخارقين - لجنة برنامج مؤتمر DevOops - في فخ شيطاني على Hangouts وأجاب على الأسئلة لمدة ساعة. (من هم جميع هؤلاء الناس - مكتوب بالتفصيل
هنا ).
تحت القطع - مقابلة ملونة مع أقلام تلوين. لكل خبير لونه الخاص:
باروخ ، ما رأيك حدث في العالم منذ DevOops الماضية؟ 
يبدو لي أن الأكثر إثارة للاهتمام ، من الواضح ، هو إقلاع Kubernetes في جميع المجالات ، ومن الاستهلاك غير الواضح - أقل ملحوظة ، ولكن ليس أقل أهمية ، من استهلاك عامل الميناء. 
أي ، قبل أن يكون عامل الميناء لا يناسب الجميع؟
لا. اعتاد Docker أن يكون شيئًا رائعًا وشابًا في حد ذاته. ثم بطريقة ما توقفت شركة الرصيف عن كونها مثيرة للاهتمام ، أي أنها موجودة ، كل شخص وكل شيء لديه ، لديها جميع الخدمات الدقيقة ، Kubernetes ، devops ، كل شيء ، أي شيء. لكن عامل الميناء نفسه ، كتكنولوجيا ، فجأة لم يعد يهتم بأحد. لا تقم بتشغيل نفس جافا على الخوادم ، فمن الواضح أن الحاويات. انها حقا تبهرني
يناقش الناس عادة ما لديهم مشاكل أو مهام مباشرة. لم تكن هناك مشاكل في عامل الميناء وهل كانت هناك؟
كان هناك الكثير من المشاكل في عامل الميناء ، وقد تم حلها بالفعل. بالإضافة إلى ذلك ، توقفنا عن استخدام أجزاء عامل الميناء المؤلمة. كان عامل الرصيف لديه أشياء يمكنه القيام بها بشكل جيد للغاية. وهناك من هم سيئون.
أعط مثالا.
على سبيل المثال ، السجون في عمليات يونيكس - كل شيء جيد جدًا وذكي هناك. انها حقا رائعة حقا ولكن على سبيل المثال ، كان الاتصال بين الخدمات الصغيرة التي يتم تشغيلها في حاويات ومجموعات وانتشار ، كان كل شيء جحيمًا وكابوسًا.
هل تعني السرب الذي حاولوا مواكبة Kubernetes؟ 
نعم ، أعني التأليف ، كان كل ذلك كابوسًا وجحيمًا. وقررنا عدم استخدامه ، ولكن فقط استخدام ما يعمل بشكل جيد ، وهو أمر مفهوم ومجاني. وأصبح عامل الميناء رائعًا من ناحية ، ومن ناحية أخرى لم يعد مثيرًا للاهتمام. عامل ميناء و عامل ميناء - جيد وجيد.
الآن ، عندما تنظر إلى برنامج جديد ، أولاً وقبل كل شيء تنظر إذا كان هناك حاوية جاهزة. يفضل من الشركة المصنعة لهذا البرنامج. ثم تشاهد كيفية فتحها ولكزها بعصا. قدم Docker لنا خدمات معقدة لكزة على آلة عمل. ليس من المهم الآن سواء كنت الخشخاش أو لينكس. يتكون Sentry نفسه من 5 إلى 6 مكونات تبدأ في تشغيلها بشكل منفصل. وإذا كانت لديك مهمة فقط لرؤية كيف يبدو هذا جيدًا ، فأرسل إشارة وشاهد كيف تتحلل هناك. الآن سيستغرق الأمر 15 دقيقة - تم إطلاقه ونشره ، وستكون القطعة في روبي ، القطعة في جافا ، لا سمح الله ، بعض Elasticearch - الذين سيموتون مع عامل الميناء نفسه.
الأهم من ذلك ، أنه سيموت في وقت لاحق. 
نعم ، هذا سحر منفصل. في السابق ، كان بإمكانك محاكاة نفسك في النظام بحيث لم يكن هناك شيء في / usr / local. ولا يزال يستيقظ - شخص في / opt ، شخص في / usr / local ، شخص آخر في مكان ما. ويتضخم نظامك ، وينمو مع كل شيء غير ضروري. هذا واحد ، والثاني - كلما كان غير ضروري لديك ، كلما زاد ناقل الهجوم عليك ، والذي يمكن أن يسيء لك بسببه. وبما أننا نطلق الآن كل هذا في عمال الموانئ ، فإن الأمن هنا والنظافة لا يحملان أي أشياء سيئة معنا.
اسمعوا ، أيها السيدات والسادة ، إنكم تعقدون مؤتمرات حول المطورين ، وهناك إذا أصبح عامل الميناء مملاً وغير مثير للاهتمام ، فماذا الآن لن يكون هناك عامل ميناء؟
أولاً ، سيكون عامل الميناء في كل مكان. فقط لأنها أصبحت مملة وغير مثيرة للاهتمام لا يعني أنها ستتوقف عن استخدامها. على العكس من ذلك ، هذا يعني أننا نستخدمه الآن ولا نهتم به. أي أنه في كل مكان. وهو ليس موضوعًا للمناقشة المنفصلة في المؤتمرات.
هل لديه أي تقارير؟ إذا دخلت البرنامج الآن وأكتب كلمة docker ، فهل لن يكون هناك شيء؟
اكتب. لنقم بهذه التجربة الرائعة.
كتب وتقول: خطوات عملية لتأمين نشر الحاوية الخاصة بك
هذا انعكاس لحقيقة أن عامل الميناء يسمح لأنظمتنا الحديثة أن تكون أكثر أمانًا بطريقة طبيعية. بالإضافة إلى ذلك ، فإنه يعكس شيئًا آخر ، والذي ربما تغير أيضًا مؤخرًا ... أصبح Devops أكثر. دعنا نقول فقط أن الشركات الكبيرة بدأت في اختراقها أكثر فأكثر. ومعهم ، بدأ المزيد والمزيد من المناقشات حول موضوع الأمن ، والذي يمكن أن يجلبه المحققون ، أو ، على العكس ، لكسر هذا الأمن. تقرير ليز حول كيفية إعداد هذا devo بشكل صحيح لإبقاء حراسك سعداء. 
هل تعرف شخصيا المتحدثين؟ من هي ليز رايس؟
ليز شخصية مهمة في المشهد الديفوبي. هي رئيس جميع KubeCons. في الواقع ، ليز ، أولاً ، هي متحدث جيد جدًا. ثانيًا ، تعمل لدى شركة Aqua Security ، وهي شركة تتعامل مع سلامة الحاويات. لن نجد شخصًا أفضل لقصة سلامة الحاويات من أولئك الذين يشاركون بشكل خاص في هذا الأمر. الأمر المثير للاهتمام على وجه التحديد في تقارير ليز ، رأيت الكثير من تقاريرها ، هو أنها تحاول حل مشكلة معقدة إلى حد ما. تكمن المشكلة في أن الأمن اليوم ، أولاً ، معقد ومعقد أكثر فأكثر ، حيث تصبح الهجمات أكثر تعقيدًا. وفقًا لذلك ، يصبح من الصعب الدفاع ضدهم ، يجب علينا تشفير معلوماتنا على REST ، يجب علينا تشفير حركة المرور ، جميع أنواع TLS ، https ، الشهادات ، البروتوكولات ... كل هذا معقد . بحرف أ في النهاية. أولاً ، الأمر صعب ، وثانيًا ، لا مفر من ذلك ، لأنه لا يمكنك القول الآن: "أوه ، أنا لا أعرف هذا ، دعنا لا نفعل https. حسنًا ، من يهتم بمن أحتاج ". نظرًا لأن Chrome سيئًا سيصرخ على الفور لجميع المستخدمين بأن كل شيء غير مؤمن معك. وهذا المزيج من التعقيد والضرورة يتجمد ، لأنه ليس من شأننا ، فنحن لسنا جميعاً آمنين. من ناحية أخرى ، تقع على عاتقنا ، لأنه لا يمكننا ببساطة تجاهل هذه الجوانب. تحاول ليز في تقاريرها نقل الجوانب الرئيسية لسلامة الحاويات ببساطة ووضوح إلى الأشخاص البعيدين عن الأمان ، وهذا أمر رائع جدًا.
هناك مشكلة أخرى أن الناس يسحبون الحاويات في أفواههم من أي مكان. غالبًا ما لا يعرفون حتى ما بالداخل. إنه شيء واحد إذا كنت تريد لصق العصا على الكمبيوتر المحمول. وشيء آخر هو جره إلى الإنتاج. ولسوء الحظ ، يسحب الكثيرون أي ضربة. أي أنك تحتاج إلى شيء يصعب تجميعه ، فهم يأخذون المنتج النهائي بشكل جيد ، إذا كان من الشركة المصنعة ، الذي اعتنى بأخذ الحاويات الأساسية العادية. وهذا هو نفس ناقل الهجوم. على سبيل المثال ، في المستقبل القريب يمكننا تجميع موجة جديدة من الحاويات التي تحمل نفس الاسم ، كما كان الحال مع وحدات النقاط ، مع الحصول على وحدات. كما هو الحال مع المجالات ، كل شيء هو نفسه. أي أن هذه ليست مشكلة جديدة ، فهي ما زالت قديمة. وعندما تصبح الخدمة سلعة ، عندما يتم توزيعها على هذا النحو ، يأتي الناس هناك ويعاقبون أولئك الذين لا يراقبون الأمن. بالمناسبة ، وبسبب هذا ، لدينا الكثير من التقارير حول الأمن.
ماذا هناك؟
لا يزال لدينا حول إدارة الأسرار من سيث فارجو. بالمناسبة ، سيكون هناك مائدة مستديرة حول الأمن معه.
هل سيث هو نفس الشخص من Google الذي كان يعمل في HashiCorp؟
قبل ذلك ، كان يعمل في Chef Software وكان نجمًا هناك عندما كان الشيف في ذروة الشعبية. ترك علامة في كل كتاب طبخ تقريبًا. البعض لم يعجبه حتى لهذا النشاط. ثم ورث الكثير في HashiCorp. ولا يزال قطار HashiCorp هذا يمتد بعده. هنا سيتحدث عن منتج HashiCorp. لن يتحدث عن جوجل. ولكن في العنوان سيكون لديه جوجل ، لذلك هذا يضيف وزنا.
بالمناسبة ، ماذا حدث للشيف؟
في بعض الأماكن ، قتل حاويات الشيف.
تطبيقات الشيف حيث تمت كتابتها وعملها - على حد علمي ، يمكن أن تستمر في العمل لفترة طويلة ، لأن إدارة التكوين نفسها لم تمت.
يا رفاق ، يمكنني أن أخبركم بمثال حي. لدينا شيء ليس في الرصيف ، ثم تحت الشيف. لأن رقاقات الثلج الخادم لم تذهب إلى أي مكان.
لقد قلت للتو ما حدث للطاه. ما ليس تحت عامل الرصيف هو تحت الشيف. ولكن تحت Docker ، لدينا كل شيء تقريبًا.
كل شيء صحيح ، ولكن لا تزال هناك خوادم طويلة العمر ، خوادم ببيانات لا يريد أحد أن يشقها. هنا سيظلون يعيشون مع الشيف لبعض الوقت ، لأن كل من كان في عالم طبيعي لا يريد العودة إلى ساحة التحكم اليدوي.
بالمناسبة ، هل هناك أي شخص يستخدم Ansible؟
نعم ، Ansible موجود أيضًا.
نحن نستخدم.
وكيف؟ لماذا Ansible؟
قدرة مذهلة على التحول إلى قمامة بسرعة شديدة. هذا هو الانطباع أوراق Ansible. لم يسبق لي أن قابلت مثل هذا التقارب إلى الجحيم في حياتي.
يبدو أن لدينا تقريرًا عن هذا!
بالضبط ولا يساعد فقط على تحويل نتيجة العمل مع Ansible إلى ما ذكرته. وهذا أمر مدهش ، آسف ، لم أره عندما كتبنا هذا كله جيد .
تقول أن كل شيء يبدأ تحت عامل الإرساء ، ولكن يجب تكوين الخوادم نفسها بطريقة ما لتشغيل برنامج مراقبة الأجهزة الافتراضية عليها؟
لا ، خذها في أمازون ...
آه ، الغشاش ، في الأمازون. فهمت.
أو Terraform - في أي مكان.
الأكثر تقدما. وحول هذا لدينا أيضا تقرير .
تغلق Terraform هذه الحاجة ، وأن هناك مجموعة من المزودين ، تبدأ أجهزتهم الافتراضية بشكل مختلف ، وأنت تستخدم Terraform لإغلاق الطبقة عندما يظهر جهازك. ثم لديك موفر في Terraform ، نفس الشيف ، نفس Ansible. يسكب بعض الموفر الطبقة التالية ، ثم يطير Docker إلى هذا الجهاز الصغير الجاهز. الربح
ويقود التقرير الشخص الذي قام بعمل وحدات aws لـ Terraform؟
لقد قام بالكثير من أجل وحدات أمازون ، ولكن هذا جزء من المجتمع. وهذا الشخص مثير للاهتمام أيضًا على النحو التالي: نظرًا لأنه عاش مع Terraform لفترة طويلة ، تشكلت بعض أفضل الممارسات في المجتمع الذي كان يتسكع فيه طوال هذه السنوات ، وهذه أفضل الممارسات ليست كافية حول Terraform ، لأنه في الأماكن يكون بسيطًا جدًا لا يسمح لك بعمل حركات غير ضرورية ، في بعض الأحيان يكون الوصف معقدًا للغاية. سيكون لديك إما وسادة قدم ، أو العكس ، بنية مترابطة معقدة للغاية. ونأمل أن يساعد أنطون بابينكو ، الذي سيتحدث فقط عن كل هذا ، في تحديد كيفية العيش مع Terraform وعدم المعاناة منه. كيفية تطوير وحداتك للاحتياجات الشخصية ، بحيث تظل نظيفة وقابلة للقراءة ، وبالمناسبة ، هناك بالطبع لا أحد يختبر أي شيء.
لم يجرب أحد هذه أقدام القدم Terraform من لغة معدنية أكثر ملاءمة لتوليد؟
هناك مثل هذه الأفكار. ونحاول ألا نفعل ذلك. هناك ، في الواقع ، لدى Terraform هياكل بيانات لا يزال بإمكانها الاستغناء عن التوليد ، ولكنها صعبة. تخيل أن لديك العديد من vpc في منطقة الأمازون في مناطق مختلفة ، وتحتاج إلى النظر فيما بينها ، وهنا تبدأ المغامرة. في كل منطقة من مناطق واجهة برمجة التطبيقات ، تختلف نقطة الدخول ، وتتحدث Terraform عن واحدة. بمعنى ، تحتاج إلى حل نقاط الدخول هذه في الوصف ، ووصف كل vpc وكذلك النظير ، والربط بين هذه vpc في مناطق مختلفة. ويجب وصف كل هذا بطريقة أو بأخرى. فعلها رفاقنا مع وحداتهم ، وبهذه الطريقة على الأقل أصبح من الممكن العيش. بشكل عام ، صعب ، صعب. ولكن إذا أعطى Terraform المزيد من الاحتمالات ، إذا كان هناك ... ما يطلق عليه عندما يتم تسخين المتغير داخل المتغير؟
Kotlin DSL. 
<الكل يضحك بجهد>
متغير متغير ، أو استيفاء - اعتمادًا على ما تعنيه.
بشكل عام ، هذه ليست لغة كاملة ، فهي مبتورة للغاية. إنه يجعلك تكتب بطريقة بسيطة قدر الإمكان ، على عكس Kotlin DSL ، حيث لديك Kotlin متكامل في يديك.
حسنًا ، كيف ، مع كل قيود DSL Kotlin ، التي تفهمها بنفسك ، يتم حلها بماذا؟
ماذا؟
حل Groovy DSL بشكل طبيعي!
استخدم العديد من TeamCity من الحاضرين هنا؟
نعم بالطبع. Groove DSL ، Kotlin DSL ، لدينا تقرير عن ذلك!
وبالطبع أنت تفعل ذلك؟
ليس أنا أفعل ذلك ، لا! سيكون لدينا فقط TeamCity مع Kotlin DSL ومقارنته مع Groovy DSL في Jenkins.
وصل شخص من JetBrains؟
لا. هذا سحر منفصل.
لدينا مستخدمين حقيقيين ، لا يوجد تسويق.
الجميع ، أنا أستسلم ، من يمكنه إعداد تقرير عن TeamCity؟
تستخدم شركة صغيرة ، تعرف على نطاق واسع في روسيا باسم Tinkoff. هنا ، هو في البرنامج .
نعم ، وأخبر القليل ، قارن مع كل المكروهين ، لكنهم استخدموا عالميًا Jenkins و Groovy DSL.
يجب علينا الذهاب والاستماع ومعرفة الدور الذي تلعبه كاريزما باروخ في اختيار التكنولوجيا.
لا يوجد. لقد استخلصت تماما من كل هذا. كل شيء سيكون صادقاً ، بدون محله.
أعني أن تينكوف أخذت كل هذه التقنيات المحببة لسبب ما ، TeamCity ليست نوعًا من الشركات قبل عشرين عامًا ، كما هو الحال عادةً مع البنوك.
تينكوف هو بنك قام بذلك منذ البداية. بنك محبو موسيقى الجاز. تبعا لذلك ، هناك تقنيات جديدة وصحيحة.
يا رفاق ، أستخدم TeamCity كل يوم حقًا ، وفي الإصدار الأخير أصبح رائعًا. TeamCity DSL متاح الآن. تعرف على المشكلة التي كانت تصل إلى أحدث إصدار. في الإصدار السابق ، إذا قمت بالتبديل إلى Kotlin DSL ، فلن يكون لديك خيار لمتابعة استخدام الواجهة. بمجرد عبور الخط ، كانت الطريقة الوحيدة للكتابة أكثر هي Kotlin فقط.
هذا كل شيء ، لقد خطوت على الجانب المظلم.
نعم ، كان هناك حد أدنى من التوثيق ، وكان أدوك. لذا جربنا وعادنا إلى تكوين XML. في أحدث إصدار ، عندما تقوم بالتبديل إلى Kotlin DSL ، فإنك تستمر في استخدام واجهة الويب ، وتشكل تصحيحات تحت غطاء المحرك ، وتقوم بتصحيح هذه الهياكل مباشرة في المستودع. ثم يمكنك الاستمرار في الكتابة بأمان في Kotlin إذا كنت قد أتقنت شيئًا بالفعل في مكان ما. يمكن لأولئك الذين لم يكرسوا بعد أن يتجولوا في الواجهة. هذا رائع يا شباب!
هذا هو التأثير المفيد لأنطون أركيبوف.
بالمناسبة ، تم ذكر جميع أنواع الممارسات هنا. هل لدينا أي تقارير مخصصة ليس للضبط ، ولكن لبعض العمليات ، والثقافة ، والجانب البشري؟
بطبيعة الحال. أولاً ، لدينا كلمة رئيسية ختامية رائعة لساشا تيتوف وكيريل تولكاتشيف ، حيث سيناقشان ما إذا كان كل شيء سيئًا في devoop أو لا يزال هناك أمل. 
يبدو من المهم بالنسبة لي أن أقول أن DevOops ربما يكون في الوقت الحالي المؤتمر المهني الوحيد الذي تنظمه مجموعة JUG.ru ، والذي يُسمح فيه بالتحدث عن الأمور الاجتماعية ومعالجة الأمور ، وعلى المستوى الرسمي.
للقيام بذلك ، كان علينا أن نتحدث عن كثب مع إدارة مجموعة JUG.ru ، ولكن النتيجة شخصيًا.
بالإضافة إلى هذه الكلمة الرئيسية الجميلة ، لدينا أيضًا تقرير من Dell EMC ، والذي له أيضًا علاقة كبيرة بالعمليات. يتعلق الأمر بفريق داخل شركة يكتب خدمات للاستخدام الداخلي. كتابة هذه الخدمة شيء آخر ، والبدء في استخدامه ، لأن جميع الأشخاص مشغولون ، ليس لديهم وقت لإتقان تقنيات محب. وبناءً عليه ، اكتب خدمة ، ثم قم ببيعها داخل الشركة. سيأتي المستخدمون إليك ، وستبدأ جميع أنواع الاحتياجات غير القياسية في الظهور ، وهنا لديك معضلة - لتطوير خدمة بحيث يمكن للكثيرين استخدامها أو إرضاء هذا الفريق بالذات. نتوقع ضوء هناك أيضا.
سيكون هناك وصف لقصة رهيبة مدتها عامان ، لم تعد مريضة كما كانت في البداية.
باروخ ، هل تقول شيئًا اجتماعيًا للغاية؟
لينا إيغولنيك ولدي تقرير عن كيفية البدء في القياس الآن هذا هو كل الخزي الذي يحدث في أجهزةنا. وبطبيعة الحال ، لدينا نوع من المقاييس التي نأتي بها إلينا من ديف والتي لا نستخدمها ولم نستخدمها أبدًا. لدينا مقاييس نأتي بها من العمليات ، والتي كانت دائمًا أفضل بكثير. السؤال هو ، ما هي مقاييس devops؟ ماذا يعني هذا؟ هل هي مجرد أخذ تلك وأخذ الآخرين ، أم أنها شيء جديد ، بعض المقاييس الجديدة؟ باختصار ، تطويرات تعتمد على البيانات .
باروخ ، القراء أحيانًا ، ساخطون من أن رفاق لجنة البرنامج يقرؤون تقاريرهم ، فهم يعتبرون هذا شيئًا غير أمين.
لقد أخذنا كل هذا في الاعتبار حقًا. على الأقل ، نحن نحاول جاهدين لجلب أكبر عدد ممكن من المتحدثين المتنوعين ، الذين ليسوا فقط من لجنة البرنامج. ولكن في الوقت نفسه ، ما زلنا نريد رؤية بعض المشاركين في أجهزة الكمبيوتر كمتحدثين. على سبيل المثال ، Alena Prokhorchik ، المهندسة الرئيسية في Rancher Labs ، والتي ربما لديها أكبر خبرة في العالم مع عمليات نشر Kubernetes المتعددة السحابة. أعتقد أن الجميع يريد أن يسمع عنها ، ولديها ما تقوله . ونحن ، كلجنة برنامج ، نتمتع بخبرتها في تقييم التقارير. ربما ، عندما يتكون المؤتمر بأكمله من متحدثين من لجنة البرنامج ، ولكل منهم خمسة تقارير ، فهذا ليس جيدًا حقًا. ولكن إذا كان لدينا متحدث جيد يريد مساعدة لجنة البرنامج ، فأنا بصراحة لا أفهم لماذا يجب علينا اختيار أحدهما أو الآخر.
باروخ ، أنت تعمل ، بالإضافة إلى أنك تسافر باستمرار بالتقارير ، بالإضافة إلى عملك في لجنة البرنامج. هل لديك حياة على الإطلاق؟ كيف يمكنك أن تفعل كل شيء؟
التطوع في مؤتمرات مجموعة JUG.ru ممتع للغاية لأنه يمنح الكثير من المتعة - بالإضافة إلى أنني أتعلم واحدة جديدة. إن تشغيل التقارير عن الأشخاص الذين يعرفون أكثر مني أمر مفيد للغاية.
فهمت. هل يريد أي شخص أن يضيف شيئًا إلى مونولوجنا مع باروخ؟
كثيرا ما أقول إنني سمعت تقارير لا أحد يسمعها .
نعم ، إن لجنة البرنامج تسمع ليس فقط ما يصل إلى المؤتمر. كانت المنافسة واحدة من كل ثلاثة. يمكننا القول أن هذا حدث ، لأنه من بين التطبيقات كان هناك العديد من التطبيقات المثيرة للاهتمام. جزء من ما قمنا بتصفية ، أوصينا في مؤتمرات أخرى.
هل كانت هناك مواضيع يجب عليك تصفيتها حسب الكمية؟ Kubernetes ، على سبيل المثال. هل يوجد شيء اخر؟
المراقبة كانت لدينا معركة للرصد.
حفنة من التقارير. الجميع يحب المراقبة.
من ربح ملك التل هذا؟
أليكسي كيربيشنيكوف ، تقرير "ماذا تعلمنا أثناء عملنا نظام إعلام الطوارئ الخاص بنا" .
هل هناك شيء أود الحصول عليه في البرنامج ، ولكن لا يوجد خبراء؟
خلعت اللسان. هناك وجه آخر للعملة ، لدينا الحبيب بدون خادم ، والذي يبدو أنه تحت الضجيج ، ولكن لم يظهر أي شخص يفكر جيدًا ويطبق عمليا كل هذا. آمل أن نحصل على واحد على الأقل. ولكن بشكل عام ، تتمتع الشركات بخبرة صناعية قليلة. باروخ ، ماذا عن الخبراء الإنجيليين؟ هم ليسوا هناك أيضا؟ أو لم يأتي إلينا أحد؟
لقد أفسدت قصة التأشيرة بأكملها الوضع بالنسبة لنا بطرق عديدة ، بما في ذلك مع المدافعين عن المطورين الذين أرادوا المجيء والتحدث عن الخوادم ، خاصة من Amazon ، حول lambdas. في التأشيرات ، للأسف ، كل شيء توقف.
وكانت هناك تقارير تعلمت فيها بالفعل شيئًا جديدًا لنفسك ، لم يكن لديك من قبل؟ أو بعض الأشياء الخارقة التي تتذكرها؟
أنا كواحد من أكثر الأشخاص غير التقنيين في لجنة البرنامج ، أجد باستمرار مجموعة من الأشياء الجديدة التي أحضرها إلى مهندسي لاحقًا ، ويقولون نعم إنها 101 التي أحضرتها إلي. لكن ليس دائمًا!
, , , ?
, , . , . - . , Ansible , . Ansible, . , , - . : , , , , . , , , .
, , . , , . .
.
?
. . , , , .
stateful , -, .
, . managed PostgreSQL … , - , — . , , , .
, - , . , ?
. Kubernetes , , . , , - , .
, . - , ? - , - , ?
— . , , , . , ( — , ) — , . JUG.ru Group , , . , , . . , (BOF). , , SRE. security, — , , , , . , , , -, , — , , :-)
- ?
, .
« , , » — , .
?
, , , . .
, , , - Java Virtual Machine, BOF . , , , - .
JVM, , , . , , , .
, — , , . , .
, . DevOops , . . , people + processes, , , .
, , TechTrain, .
, . , , , , . , TechTrain, . , TechTrain . JUG.ru Group, — . , . , . , , , .
, , — « » ( ).
, . -, , , . — , .
DevOops !
, , Joker , Java . , , — .
, , , DevOops - . , every company is a software company, - .
شكرا لكم جميعا على المقابلة! سنلتقي بكم عدة مرات في إعداد المقالات ، ولكن مع قرائنا من هبر سنلتقي فقط في DevOops. كل التوفيق ونراك قريبا!
سيعقد مؤتمر DevOops في 14 أكتوبر 2018 في سان بطرسبرج. إذا أعجبك البرنامج الذي كنا نناقشه هنا فجأة ، فتأكد من الحضور. التذاكر هنا .