عُقدت قمة DevOps Enterprise العادية في لندن في الفترة من 23 إلى 25 يونيو 2020. يمكن كتابة عبارة "في لندن" بين علامتي اقتباس ، حيث أدى الوباء وظيفته وعقد المؤتمر على الإنترنت. هناك أشياء سيئة هنا (لا تزال الشبكات تعاني كثيرًا) وأشياء جيدة: يمكنك أن تأخذ استراحة بين التقارير بعيدًا عن جميع الأشخاص ، ويمكنك تخصيص بضعة أيام كاملة لدراسة التقارير التي تهمك ، والتركيز - وهذا مفيد جدًا ... في الآونة الأخيرة كنت في لقاء "في تشيليابينسك" ، في اليوم التالي - "في نوفوسيبيرسك" ، وبعد أيام قليلة - في كاليفورنيا: من الصعب جسديًا القيام بذلك. بالطبع ، هناك تسجيلات ، ولكن يبدو أن الشعور بالوقت المخصص للتعلم يساعدك على التعلم.
لقد تأصلت تنسيقات تقارير المؤتمرات بالفعل على حبري ، وأصبحت الرغبة في التطور في الظروف التي تجلس فيها في المنزل قوية بشكل خاص (عليك القيام بشيء ما) - وهنا يبرز السؤال: هناك الكثير من المؤتمرات ... كيف ترى كل شيء تريد رؤيته؟
وهنا اعتقدت أنه يمكنني محاولة إعداد تقرير عن المؤتمر بتنسيق مختلف - ليس لأقول ما هي التقارير (لهذا نشرتُ "بثًا مباشرًا للنص المباشر" من التقارير التي استمعت إليها) ، ولكن لكتابة مقال يلخص الاستنتاجات والاتجاهات الحالية ، سوف تشير إلى أين تتجه للحصول على أحدث المعرفة.
ما هي قمة DevOps Enterprise؟ كيف تختلف عن المؤتمرات الأخرى؟
أي مقال عن مؤتمر DevOps ، بالطبع ، يجب أن يبدأ بمناقشة ما هو DevOps - وبالطبع ، سئم الجميع منه. لذلك ، سأحاول أن أكون موجزة!
في الواقع ، من المرجح أن يتفق كل من يجادل على شيء واحد على الأقل - أن "تطوير الأجهزة عبارة عن مجموعة من الممارسات التي تسهل توصيل البرامج وإدارة البنية التحتية". الاختلافات الوحيدة هي أن مجموعة واحدة (وغالبًا ما تكون هذه "مدراء") تقول "يجب أن تكون مناقشة الممارسات عملية" ، والمجموعة الثانية (وهذه هي التنمية ، وفي أغلب الأحيان ، الإدارة في التنمية) تعتقد أن "هذه فلسفة ومنهجية ".
قد أخاطر بتحمل الغضب بسبب "التبسيط" ، ولكن في الجوهر: من أجل التطوير ، أدى إدخال أساليب وقدرات "المشرف" إلى تغيير عملية التطوير نفسها أيديولوجيًا وتحويل DevOps إلى Agile جديد - عندما نسمع عن المؤتمرات الإدارية حول DevOps ، نسمع عن التغييرات في المنهجية تطوير. و DevOps Enterprise Summit هي واحدة من تلك المؤتمرات المفيدة لـ "المسؤولين": كانت هناك أيضًا تقارير أقرب إلى التقنية.
لذا ، تم عقد قمة DevOps Enterprise منذ عام 2014 ، ويتم تنظيمها من قبل IT Revolution مع مؤسس جين كيم ، المعروف للكثيرين من كتاب "Project Phoenix". IT Revolution هو الناشر الذي أطلق سلسلة من الكتب حول DevOps وروابطها إلى Agile. لماذا انتربرايز؟ هذه نقطة مهمة بشكل خاص.
يعد تطبيق منهجيات رشيقة في شركة صغيرة أمرًا سهلاً: في الشركات متعددة الأشخاص ، كانت موجودة على الأرجح منذ البداية - ما عليك سوى الاتصال بها بهذه الطريقة. مع شركات الآلاف ، وعشرات الآلاف من الناس ، كل شيء أكثر تعقيدًا. هناك عدد كبير من العمليات فيها ، بنيت بحيث يستمر هذا العملاق في التحرك ، ويمكن مقارنة ذلك بسفينة كبيرة. عندما تنتقل سفينة عبر المحيط من البر الرئيسي إلى آخر ، فإنها تؤدي دورها ، ولكن لا يمكن للسفينة تغيير المسار وتغيير المسار في أقصر وقت ممكن - وهذا يستغرق وقتًا ، خاصة في أعمال التكنولوجيا. يمكن لشركة شابة من عدد قليل فقط أن تبني نموذجًا أوليًا في غضون أيام ستبنيها شركة الآلاف لسنوات - إذا لم تتغير.لذلك ، تريد الشركات الكبيرة تغيير واستخدام أساليب "الشباب" ، لكنهم بحاجة إلى فهم كيفية عدم تعطيل عملياتهم. لقد قدمت بالفعل مثالاً في مقال آخر: في Excel 1900 يعتبر عامًا كبيسًا ، ويتم ذلك للتوافق مع الإصدارات السابقة من إصدارات Lotus 1-2-3 ، التي كان بها مثل هذا الخطأ. تم إصدار هذه الإصدارات في الثمانينيات ، والسؤال هو: هل يجب الحفاظ على هذا التوافق؟ إلى أي مدى يمكن السماح بالأخطاء في نهج "سنقوم بإصلاحها لاحقًا" عندما تقوم بتثبيت برنامج في البنوك على خوادم غير متصلة بالإنترنت بشكل عام؟ كيف يمكنك الحفاظ على نفس المرونة؟ كان هذا ما كان المؤتمر حوله.تم إصدار هذه الإصدارات في الثمانينيات ، والسؤال هو: هل يجب الحفاظ على هذا التوافق؟ إلى أي مدى يمكن السماح بالأخطاء في نهج "سنقوم بإصلاحها لاحقًا" عندما تقوم بتثبيت برنامج في البنوك على خوادم غير متصلة بالإنترنت بشكل عام؟ كيف يمكنك الحفاظ على نفس المرونة؟ كان هذا ما كان المؤتمر حوله.تم إصدار هذه الإصدارات في الثمانينيات ، والسؤال هو: هل يجب الحفاظ على هذا التوافق؟ إلى أي مدى يمكن السماح بالأخطاء في نهج "سنقوم بإصلاحها لاحقًا" عندما تقوم بتثبيت برنامج في البنوك على خوادم غير متصلة بالإنترنت بشكل عام؟ كيف يمكنك الحفاظ على نفس المرونة؟ كان هذا ما كان المؤتمر حوله.
شكل
يحاول كل مؤتمر معرفة كيفية توصيل نفسه عبر الإنترنت ، وهو أمر مثير للاهتمام. في DOES ، يمكن ملاحظة ما يلي:
- لا تزال التقارير مقسمة حسب المسار ، ويمكن للمشاهد التبديل بين المسارات في العملية.
- تم تسجيل التقارير قبل يوم المؤتمر ، وذلك لتجنب المشاكل الفنية مع البث ، المتكلم أثناء التقرير في قناة الركود ويتواصل مع الجمهور. ربما هذا هو الشيء الأكثر إثارة للاهتمام الذي تعلمته من المنظمة. الحل متناقض - من ناحية ، يختفي التفاعلي ، من ناحية أخرى ، المزيد من الوقت للأسئلة (والمزيد من الفرص للمتكلم للإجابة على المزيد من الأسئلة). ومع ذلك ، على سبيل المثال ، استمعت بشكل رئيسي إلى التقرير ولم أرغب في التحول إلى المناقشة ، لذلك جئت في النهاية ، عندما كان هناك القليل من الوقت المتبقي وجاء متكلم جديد إلى التقرير التالي.
- , -, .
- , , , , « », - , , , .
- -Horses, -Unicorns — -, « », , — , , .. , - «-» , , ( ) ( Gene Kim).
- DevOps « » — scenius. Scenius «» — genius, , , , scenius, ( Gene Kim). (. medium.com/@stevesargon/steal-like-devops-artist-1-you-dont-have-to-be-a-genius-or-googler-6e9f17c14fb5 Scenius.)
- Platform Engineering, «» «», (DevOps Journey at Adidas III, Exploring Data in the Cloud Fernando Cornago VP, Platform Engineering, Daniel Eichten VP, Enterprise Architecture, Adidas ). (. softwareengineeringdaily.com/2020/02/13/setting-the-stage-for-platform-engineering platform engineering platform team). , , , , . — , , . , , (platform advisory/community management/platform operation/platform evolution).
DevOps Dojo. . , . SRE- Uptime community, , ? Dojo — , , . DevOps- Target, , , , , , , . . youtu.be/1FMktLCYukQ
- Swiss Re — , 156 , DevOps- . , « ». «» — «» CEO, , .. , , , Gartner-, 76% DevOps- «, ». . — , . , «» DevOps- — . . , , : Hermes Germany GmbH , CIO, « », «» .
- , — . State of Devops, Gene Kim Accelerate.
- , , DevOps And Modernization 2.0 (CSG) Scott Prugh — DevOps . , — , : Cobol-, 3,7 IBM High Level Assembler Java ! : .
الكتب المذكورة تستحق القراءة:
طوبولوجيا الفريق في العمل ، وتسريع: بناء وتطوير منظمات التكنولوجيا عالية الأداء .
وأنا أكثر انتظامًا من المدونة هنا ، فأنا أدير قناة برقية خاصة بي ، واشترك.