نحن نتحدث بالطبع عن . إذا لم تدخل في التفاصيل، فسنعقد مؤتمرًا في 30 سبتمبر و1 أكتوبر حول الجمع بين عمليات التطوير والاختبار والتشغيل، وإذا دخلت في التفاصيل، من فضلك، تحت القط.
ضمن نهج DevOps، تتشابك جميع أجزاء التطور التكنولوجي للمشروع، وتحدث بالتوازي وتؤثر على بعضها البعض. من الأهمية بمكان هنا إنشاء عمليات تطوير آلية يمكن تغييرها ومحاكاتها واختبارها في الوقت الفعلي. وهذا يساعدك على الاستجابة الفورية للتغيرات في السوق.
نريد في المؤتمر أن نبين كيف يؤثر هذا النهج على تطوير المنتج. كيف يتم ضمان موثوقية النظام وقابليته للتكيف للعميل. كيف تقوم DevOps بتغيير هيكل الشركة ونهجها لتنظيم عملية عملها.
خلف الكواليس
من المهم بالنسبة لنا أن نعرف ليس فقط ما تفعله الشركات المختلفة في إطار نهج DevOps، ولكن أيضًا أن نفهم سبب القيام بكل هذا. لذلك، قمنا بدعوة ليس فقط الخبراء للانضمام إلى لجنة البرنامج، ولكن أيضًا المتخصصين الذين يرون خطاب DevOps من مواقع مختلفة:
- كبار المهندسين.
- المطورين؛
- يقود الفريق؛
- مدير التكنولوجيا.
وهذا من ناحية يخلق صعوبات وصراعات عند مناقشة طلبات التقارير. إذا كان المهندس مهتمًا بتحليل حادث كبير، فمن المهم للمطور أن يفهم كيفية إنشاء برنامج يعمل في السحابة والبنى التحتية. ولكن من خلال الموافقة، نقوم بإنشاء برنامج سيكون ذا قيمة ومثيرًا للاهتمام للجميع: من المهندسين إلى CTO.
الهدف من مؤتمرنا ليس فقط اختيار التقارير الأكثر إثارة للاهتمام، ولكن تقديم الصورة العامة: كيف يعمل نهج DevOps في الممارسة العملية، وما هو نوع الضرر الذي يمكن أن تتعرض له عند الانتقال إلى عمليات جديدة. وفي الوقت نفسه، نقوم ببناء جزء المحتوى، والانتقال من مشكلة العمل إلى تقنيات محددة.
ستبقى أقسام المؤتمر كما هي في .
- منصة البنية التحتية.
- البنية التحتية كرمز.
- التسليم المستمر.
- تعليق.
- الهندسة المعمارية في DevOps و DevOps لـ CTO.
- ممارسات SRE.
- التدريب وإدارة المعرفة.
- الأمن، DevSecOps.
- تحول DevOps.
دعوة لتقديم الأوراق: ما نوع التقارير التي نبحث عنها؟
لقد قمنا بتقسيم الجمهور المحتمل للمؤتمر بشكل مشروط إلى خمس مجموعات: المهندسين، والمطورين، والمتخصصين في مجال الأمن، وقادة الفرق، ومدير التكنولوجيا التنفيذي. كل مجموعة لديها دوافعها الخاصة للحضور إلى المؤتمر. وإذا نظرت إلى DevOps من هذه المواقف، فيمكنك فهم كيفية التركيز على موضوعك ومكان التركيز.
للمهندسين، الذين يقومون بإنشاء منصة للبنية التحتية، من المهم فهم الاتجاهات الحالية، لفهم التقنيات الأكثر تقدمًا الآن. سيكونون مهتمين بالتعرف على تجربة الحياة الواقعية في استخدام هذه التقنيات وتبادل الآراء. سيكون المهندس سعيدًا بالاستماع إلى تقرير يحلل بعض الحوادث الخطيرة، ونحن بدورنا سنحاول اختيار مثل هذا التقرير وصقله.
للمطورين من المهم أن نفهم مثل هذا المفهوم التطبيق السحابي الأصلي. أي كيفية تطوير البرمجيات بحيث تعمل في السحب والبنى التحتية المختلفة. يحتاج المطور إلى تلقي التعليقات من البرنامج باستمرار. نريد هنا أن نسمع حالات حول كيفية بناء الشركات لهذه العملية، وكيفية مراقبة أداء البرامج، وكيفية عمل عملية التسليم بأكملها.
متخصصون في الأمن السيبراني من المهم فهم كيفية إعداد العملية الأمنية بحيث لا تؤدي إلى تعطيل عمليات التطوير والتغيير داخل الشركة. ستكون المواضيع المتعلقة بالمتطلبات التي تفرضها DevOps على هؤلاء المتخصصين مثيرة للاهتمام أيضًا.
قادة الفريق يريدون أن يعرفواكيف تتم عملية التسليم المستمر في الشركات الأخرى. ما هو المسار الذي سلكته الشركات لتحقيق ذلك، وكيف قامت ببناء عمليات التطوير وضمان الجودة داخل DevOps. يهتم قادة الفريق أيضًا بالسحابة الأصلية. وأيضا أسئلة حول التفاعل داخل الفريق وبين فرق التطوير والهندسة.
إلى CTO الشيء الأكثر أهمية هو معرفة كيفية ربط كل هذه العمليات وتعديلها وفقًا لاحتياجات العمل. إنه يتأكد من أن التطبيق موثوق به لكل من الشركة والعميل. وهنا تحتاج إلى فهم التقنيات التي ستعمل من أجل أي مهام تجارية، وكيفية بناء العملية برمتها، وما إلى ذلك. CTO مسؤول أيضًا عن إعداد الميزانية. على سبيل المثال، يجب عليه أن يفهم مقدار الأموال التي يجب إنفاقها على إعادة تدريب المتخصصين حتى يتمكنوا من العمل في DevOps.
إذا كان لديك ما تقوله في هذه الأمور، فلا تصمت، . الموعد النهائي لتقديم الأوراق هو 20 أغسطس. كلما قمت بالتسجيل مبكرًا، زاد الوقت المتاح لك لإنهاء تقريرك والتحضير لعرضك التقديمي. لذا، لا تتأخر.
حسنًا، إذا لم تكن لديك حاجة للتحدث علنًا، فقط وتعالوا يومي 30 سبتمبر و1 أكتوبر للتواصل مع الزملاء. ونعد أنها ستكون مثيرة للاهتمام وملهمة.
كيف نرى DevOps
لفهم ما نعنيه بـ DevOps بالضبط، أوصي بقراءة (أو إعادة قراءة) تقريري "" أثناء سيري عبر موجات السوق، لاحظت كيف كانت فكرة DevOps تتحول في شركات مختلفة الحجم: من شركة ناشئة صغيرة إلى شركات متعددة الجنسيات. التقرير مبني على سلسلة من الأسئلة، من خلال الإجابة عليها يمكنك فهم ما إذا كانت شركتك تتجه نحو DevOps أو ما إذا كانت هناك مشاكل في مكان ما.
يعد DevOps نظامًا معقدًا، ويجب أن يتضمن ما يلي:
- منتج رقمي.
- وحدات الأعمال التي تطور هذا المنتج الرقمي.
- فرق المنتج التي تكتب الرمز.
- ممارسات التسليم المستمر.
- المنصات كخدمة.
- البنية التحتية كخدمة.
- البنية التحتية كرمز.
- ممارسات الموثوقية المنفصلة داخل DevOps.
- ممارسة التغذية الراجعة التي تصف كل شيء.
وفي نهاية التقرير يوجد رسم تخطيطي يعطي فكرة عن نظام DevOps في الشركة. سيسمح لك بمعرفة العمليات التي تم تبسيطها بالفعل في شركتك وتلك التي لم يتم إنشاؤها بعد.
يمكنكم مشاهدة الفيديو الخاص بالتقرير .
والآن ستكون هناك مكافأة: العديد من مقاطع الفيديو من RIT++ 2019، والتي تتناول المشكلات الأكثر عمومية المتعلقة بتحويل DevOps.
البنية التحتية للشركة كمنتج
يقود Artyom Naumenko فريق DevOps في Skyeng ويهتم بتطوير البنية التحتية لشركته. وأخبرنا كيف تؤثر البنية التحتية على العمليات التجارية في SkyEng: كيفية حساب عائد الاستثمار لها، وما هي المقاييس التي ينبغي اختيارها للحساب وكيفية العمل على تحسينها.
على الطريق إلى الخدمات المصغرة
تقدم شركة Nixys الدعم لمشاريع الويب المزدحمة والأنظمة الموزعة. تحدث مديرها الفني، بوريس إرشوف، عن كيفية ترجمة منتجات البرمجيات، التي بدأ تطويرها قبل 5 سنوات (أو حتى أكثر)، إلى منصة حديثة.
كقاعدة عامة، مثل هذه المشاريع هي عالم خاص حيث توجد زوايا مظلمة وقديمة من البنية التحتية التي لا يعرفها المهندسون الحاليون. كما أن أساليب الهندسة المعمارية والتطوير التي تم اختيارها من قبل أصبحت قديمة ولا يمكنها تزويد الشركة بنفس وتيرة التطوير وإصدار الإصدارات الجديدة. ونتيجة لذلك، يتحول كل إصدار منتج إلى مغامرة مذهلة، حيث يسقط شيء ما باستمرار، وفي مكان غير متوقع.
يواجه مديرو مثل هذه المشاريع حتماً الحاجة إلى تحويل جميع العمليات التكنولوجية. وقال بوريس في تقريره:
- كيفية اختيار الهندسة المعمارية المناسبة للمشروع وترتيب البنية التحتية؛
- ما هي الأدوات التي يجب استخدامها وما هي المخاطر التي نواجهها في طريق التحول؛
- ما العمل التالي.
أتمتة الإصدارات أو كيفية التسليم بسرعة ودون ألم
ألكسندر كوروتكوف هو المطور الرائد لنظام CI/CD في CIAN. تحدث عن أدوات التشغيل الآلي التي مكنت من تحسين الجودة وتقليل الوقت اللازم لتسليم التعليمات البرمجية إلى الإنتاج بمقدار 5 مرات. لكن مثل هذه النتائج لا يمكن تحقيقها بالأتمتة وحدها، لذلك اهتم ألكسندر أيضًا بالتغيرات في عمليات التطوير.
كيف تساعدك الحوادث على التعلم؟
يقوم Alexey Kirpichnikov بتنفيذ DevOps والبنية التحتية في SKB Kontur لمدة 5 سنوات. على مدار ثلاث سنوات، حدث ما يقرب من 1000 عملية وهمية بدرجات متفاوتة من الملحمة في شركته. من بينها، على سبيل المثال، 36% منها كانت بسبب طرح إصدار منخفض الجودة في الإنتاج، و14% كانت بسبب أعمال صيانة الأجهزة في مركز البيانات.
إن أرشيف التقارير (بعد الوفاة) التي يحتفظ بها مهندسو الشركة لعدة سنوات متتالية يجعل من الممكن الحصول على مثل هذه المعلومات الدقيقة حول الحوادث. يتم كتابة تشريح الجثة من قبل المهندس المناوب، الذي كان أول من استجاب لإشارة الطوارئ وبدأ في إصلاح كل شيء. لماذا يعذب المهندسون الذين يكافحون ليلاً مع واجهات الوجه من خلال كتابة التقارير؟ تتيح لك هذه البيانات رؤية الصورة كاملة وتحريك تطوير البنية التحتية في الاتجاه الصحيح.
في كلمته، شارك أليكسي كيفية كتابة تقرير مفيد حقًا بعد الوفاة وكيفية تنفيذ ممارسة مثل هذه التقارير في شركة كبيرة. إذا كنت تحب القصص التي تتحدث عن فشل شخص ما، شاهد مقطع الفيديو الخاص بالأداء.
نحن ندرك أن رؤيتك لـ DevOps قد لا تتطابق مع رؤيتنا. سيكون من المثير للاهتمام معرفة كيف ترى تحول DevOps. شارك تجربتك ورؤيتك لهذا الموضوع في التعليقات.
ما هي التقارير التي قبلناها بالفعل في البرنامج؟
اعتمدت لجنة البرنامج هذا الأسبوع 4 تقارير: حول الأمن والبنية التحتية وممارسات SRE.
ربما يكون الموضوع الأكثر إيلامًا في تحول DevOps: كيفية التأكد من أن الرجال من قسم أمن المعلومات لا يدمرون الروابط التي تم إنشاؤها بالفعل بين التطوير والتشغيل والإدارة. بعض الشركات تدير أعمالها بدون وجود قسم لأمن المعلومات. كيفية ضمان أمن المعلومات في هذه الحالة؟ حوله منى أرخيبوفا من sudo.su. ومن تقريرها نتعلم:
- ما الذي يجب حمايته وممن؛
- ما هي العمليات الأمنية الروتينية؟
- وكيفية تقاطع عمليات تكنولوجيا المعلومات وأمن المعلومات؛
- ما هو CIS CSC وكيفية تنفيذه؛
- كيف وبأي مؤشرات لإجراء فحوصات منتظمة لأمن المعلومات.
ويتعلق التقرير التالي بتطوير البنية التحتية كرمز. تقليل كمية الروتين اليدوي وعدم تحويل المشروع بأكمله إلى فوضى، هل هذا ممكن؟ لهذا السؤال مكسيم كوستريكين من اكستينس. تستخدم شركته Terraform للعمل مع البنية التحتية لـ AWS. الأداة مريحة، ولكن السؤال هو كيفية تجنب إنشاء كتلة ضخمة من التعليمات البرمجية عند استخدامها. سوف تصبح صيانة مثل هذا الإرث أكثر تكلفة كل عام.
سيوضح مكسيم كيفية عمل أنماط وضع التعليمات البرمجية، بهدف تبسيط الأتمتة والتطوير.
آخر سنسمع عن البنية التحتية من فلاديمير ريابوف من Playkey. سنتحدث هنا عن منصة البنية التحتية، وسنتعرف على:
- كيفية فهم ما إذا كان يتم استخدام مساحة التخزين بشكل فعال؛
- كيف يمكن لعدة مئات من المستخدمين الحصول على 10 تيرابايت من المحتوى إذا تم استخدام 20 تيرابايت فقط من مساحة التخزين؛
- وكيفية ضغط البيانات 5 مرات وتقديمها للمستخدمين في الوقت الفعلي؛
- كيفية مزامنة البيانات بسرعة بين عدة مراكز بيانات؛
- كيفية القضاء على أي تأثير للمستخدمين على بعضهم البعض عند استخدام جهاز افتراضي واحد بالتتابع.
سر هذا السحر هو التكنولوجيا ZFS لـ FreeBSD وشوكتها الطازجة ZFS على نظام Linux. سوف يقوم فلاديمير بمشاركة الحالات من Playkey.
ماتفي كوكوي من Amixr.IO جاهز مع أمثلة من الحياة ، ماذا او ما SRE وكيف يساعد في بناء أنظمة موثوقة. يقوم Amixr.IO بتمرير حوادث العملاء من خلال الواجهة الخلفية الخاصة به، وقد تعاملت بالفعل مع العشرات من الفرق المناوبة حول العالم مع 150 ألف حالة. وفي المؤتمر، سيشارك ماتفي الإحصائيات والأفكار التي تراكمت لدى شركته من خلال حل مشكلات العملاء وتحليل حالات الفشل.
مرة أخرى، أحثك على عدم الجشع ومشاركة تجربتك كساموراي في DevOps. يخدم للحصول على تقرير، وسيكون لدينا أنا وأنت شهرين ونصف لإعداد خطاب ممتاز. إذا أردت أن تكون مستمعاً، قم بزيارة النشرة الإخبارية بتحديثات البرنامج وفكر جديًا في حجز التذاكر مسبقًا، لأنها ستصبح أكثر تكلفة مع اقتراب موعد المؤتمر.
المصدر: www.habr.com