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



تستند المواد إلى تقرير حوار قدمه سيرجي بيردنيكوف (التاج الذهبي) وأرتيم كاليشكين (CFT) من مؤتمر أكتوبر DevOops 2017 . تحت قص - نص الفيديو ونسخة من التقرير.




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



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

الجزء الثاني هو خدمات المعالجة. نقدم هنا خدمات مباشرة للأفراد أو من خلال شركائنا. هذه هي شبكات التداول الكبيرة والبنوك والمشاركين الآخرين في سوق الخدمات المالية. هنا نعمل على دورة كاملة من الفكرة إلى التطوير والتنفيذ والمزيد من العمليات.

نحن نعمل مع Sergey في جزء المعالجة لشركتنا. حول كيفية وصولنا إلى القصة مع DevOps في هذه المعالجة ، سنخبرنا.

ماذا كان

سيرجي: إرثنا كان مصرفيًا تمامًا. قامت الشركة في البداية بصنع منتجات مصرفية ، على التوالي ، كل شيء كان مألوفًا: البنية التحتية الكاملة لـ SPARC فقط ، ومراكز البيانات الخاصة بها ، تم كتابة القلب بالكامل في Oracle. كود PL / SQL ، الكثير من الأشياء - ليس من السهل قياسه.

قمنا بقياس الحجم عموديًا فقط: اشترينا قطعة قوية من الحديد ، واستخدمناها حتى أصبحت قديمة ، واستبدلناها بقطعة جديدة وتم نقل القديمة إلى التدريج.

كتب أيضا الكثير من التعليمات البرمجية في جافا. لقد حجزنا من خلال احتياطي دافئ: يوجد مركز بيانات ، والهيكل المنسوخ بالكامل - مفاتيح ، خوادم ، الكل في واحد ، الترباس إلى الترباس.



هنا يمكنك أن ترى كيف بدا الهيكل بأكمله من وجهة نظر العمليات. كانت هناك مديريات تقنية منفصلة ديف ، ثم الجدران النارية بالنار. بعد ذلك كانت تكنولوجيا المعلومات المركزية ، والتي شاركت في الإزالة والنشر وما إلى ذلك. بمعنى ، كتب Devs تعليمات كبيرة ، وتم تقسيم عمليات تكنولوجيا المعلومات إلى ثلاثة أقسام:

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

Artem: DevOps ليس هنا في هذه المرحلة بعد ، لقد عملنا وفقًا للوائح ، والتي لم يكن سيرجي سعيدًا بها.

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

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

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

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

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

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

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

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

Artem: حاولنا الانتقال مع التطبيقات إلى Confluence ، نظرًا لأنه من غير المناسب الإرسال في Word - كان من الممكن تشكيل شيء خاطئ. في Confluence ، خططوا دائمًا لتحميل الإصدار الحالي مع جميع التغييرات.

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

لقد أدركنا أنه بغض النظر عن الانحراف مع تعليمات الصفحة ، فقد تحول كل هذا إلى هراء كامل ، بغض النظر عن كيفية تأطيره.

كانت هناك متطلبات مسبقة مهمة لوقت التوقف الطويل في الليل ، مما أدى إلى ضعف الإقلاع بعد التثبيت ، إلى عضادات ، وعدد كبير من الصراعات بين التنمية والتشغيل.

• الكثير من الأخطاء البشرية في إرسال التغييرات ؛
• البحث المستمر عن المذنب ؛
• معدل إزالة الوحدات الجديدة حتى 3 أسابيع ؛
• نقاط الفشل الفردية (التحجيم العمودي فقط) ، عدم التوازن ؛
• وقت التعطل المخطط خلال التحديثات لمدة ساعتين.

خلفية التحول

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

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

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

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

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

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

Artem: يعد وقت التعطل المجدول لمدة ساعتين من وقت التحديث أحد العوامل الحاسمة لسبب بدءنا في البحث عن حل ، وكيفية الابتعاد عنه.

الحقيقة هي أننا نقدم خدمات مالية وخدمات معالجة. نحن نعمل في دول أجنبية. في ذلك الوقت ، عملوا بالفعل في 11 منطقة زمنية ، في عام 2013 كان لدينا ساعة واحدة فقط من النوافذ ، عندما كان استخدام الخدمة في حده الأدنى ، تم تقليل عدد مكالمات العملاء ، وجاء الهدوء ، ويمكن القيام بشيء ما.

بشكل مشروط ، يمكننا القيام بالعمل من ساعة إلى ساعتين في الليل. ساعتان أكثر بكثير من هذه النافذة. كنا نقترب من كارثة ، إن لم يكن من أجل التحول ، لأنه الآن ليس لدينا نوافذ ماديا.

الإجابة على كل هذه المشاكل حصلت على فكرة ، محاولة لمعرفة ما هو DevOps.

في ذلك الوقت ، جاء زميلنا مع HighLoad ، وكنت مشغولاً بتنفيذ CMBD ، لأنني كنت بحاجة إلى ذلك حتى لا تنكسر التكوينات ويمكنني على الأقل إدارة شيء ما. استمع إلى تقرير ساشا تيتوف ، الذي تحدث عن بعض الشيف. يبدو أن إدارة التكوين أيضا

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

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

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

وذلك عندما توصلت إلى هذه الفكرة ، مع الإعلان الأول عما أريد الحصول عليه. هذا هو مستند 2013 ، وهو أول مستند تم إنشاؤه في الشركة حول DevOps.

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



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

القادم للانضمام إلى الحراس. لقد مروا من خلالنا بالكامل: نوع من المرحلة المتطابقة! ولديهم صورة مثالية للعالم: على محرك الأقراص المحمول ، ونقل الإصدارات ، سنوقع عليها بمفتاح PGP ، وسيكون كل شيء على ما يرام - الخدمة المثالية. لقد عملنا معهم لفترة طويلة للوصول إلى النهاية ، فقط بفضل أنشطة المشروع قمنا بعمل شيء.

Artem: هنا انطلقنا من القيم: هذا هو المكان الذي نخسر فيه المال ، وهذا أمر بسيط غير مقبول.

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

كانت هناك عملية إقناع وإجبار: اقترحنا استخدام أفكارنا على عدد محدود من الأنظمة.

سيرجي: طُلب منا كتابة جميع المخاطر وكيفية الإفراج عنها. كان من الضروري التنسيق مع الأشخاص الذين قد يخسرون المال. وقال المبرمجون أيضًا: "لقد كتبنا نوعًا من التعليمات البرمجية ، وكنا ننقل الرمز البريدي بشكل طبيعي ، وكتبنا التعليمات ، ونوعًا آخر من التعليمات البرمجية لنكتبها من أجل الإزالة؟!"

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



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

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

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

الفكرة الأولى هي كتابة إدارة التكوين بأنفسنا ، هناك العديد من المطورين. ثم تذكرنا كل ما كتبناه بأنفسنا ورفضنا - كلنا نشعر.

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

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

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



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

أرتيم: وعلى هذا ، وبشرط ، هيكل القيادة ، بدأنا في الانتقال إلى التكنولوجيا.

سيرجي: الآن سنخبرك كيف اخترنا النظام. لقد كان مثيرا للاهتمام بما فيه الكفاية. بادئ ذي بدء ، حاولنا الشيف ، لسبب واحد بسيط - عرفنا المعلم الذي يعرف الشيف. ثم جربنا Puppet ، لأنه في ذلك الوقت أعلنت Oracle عن دعم Puppet.

حاول Ansible أيضًا ، لكن كلا الفريقين لم يعجبه كنظام. كانت هناك أيضًا مشكلات أمنية: كان Ansible في عام 2013 مختلفًا تمامًا عن المشكلة الحالية.

أطلقنا مشروعين مختلفين بنفس الوظيفة بالتوازي. وكل شيء يعمل بشكل جيد ، كان هناك شعور بأن هناك خطأ ما هنا ويجب تركه وحده. كيف اخترنا؟

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

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

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

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

في الواقع ، اخترنا ليس RPM ، ولكن IPS - مدير حزم Solaris. استوردنا أنفسنا من الإصدار الحادي عشر إلى العشرة الأوائل ، التي وقفت ، وبدأنا في استخدامها. كان الرفض من عكازات باش المكتوبة ذاتيا و zip-s في تلك اللحظة هو القرار الأكثر صحة.

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

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

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

في ذلك الوقت ، أدركنا أنه لا يوجد حل مثالي. فقط خذ كل ما كسبناه وتحمله. كان للمطورين نظام التجميع الخاص بهم ، وقمنا بتسليم أنفسنا. لم يكن هناك خيار مثالي ، ولا يزال يعمل مع فرق مختلفة بطرق مختلفة. لا يوجد مثالي.

لدينا أيضًا مجموعة كبيرة ، معظم التعليمات البرمجية الخاصة بنا مضمنة في قاعدة البيانات: كل المعالجة المالية ، والتي ، للأسف ، تحتفظ بنموذج "كلما كانت أقرب إلى البيانات ، كلما كانت أسرع في العمل". توافق فاولر على بيع أوراكل. المعاملات المالية معلقة في PS / SQL ، لم نجد أي منتج مفتوح المصدر من شأنه أن يساعد في حل مشكلتنا مع الإصدارات والتسليم. ربما كان كذلك ، لكننا بدأنا في كتابة آلة موسيقية خاصة بنا.

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

والحقيقة هي أننا نحتاج إلى رفع بيئة متشابهة تقريبًا في الأداء وملؤها ببيانات متشابهة في الحجم ، ولا تقل أهمية ، الأصالة ، حتى تمر اختبارات المرحلة بشكل صحيح.

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

ثم اكتشفنا مشكلة في نقل البيانات من المعركة إلى المرحلة لملئها بنفس كمية البيانات. من المستحيل أنه لا يمكن لأي شخص الوصول إلى بيانات العملاء وفقًا للمستندات.

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

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

نحن نبتعد عن حالة الأداء المطلقة ، ونراقب التغييرات. الوضع لم يزداد سوءا مقارنة بالنسخة السابقة ، والتي ، في رأينا ، لم تكن سيئة في الأداء.



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

سيرجي: كانت هناك تغييرات طفيفة من تقديمك. مرة أخرى ، تدفقت المسؤوليات من تكنولوجيا المعلومات المركزية إلى المديرية الفنية.

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



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

أرتيوم:هنا مثال ، نقدم عرضًا من خلال git. يأتي المدير نفسه ويقدم عرضًا للمعركة.

سيرجي: وجدنا أدوات مثل Gitlab ، أحببنا أن بإمكان الشخص العمل باستخدام واجهة رسومية. يوجد زر "تنزيل" ، وقد لا يفهم المستخدم حتى ما يفعله الالتزام بالفعل.

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

كانت الصعوبة الأخرى هي كيفية حساب مثل هذه اللحظات. في الروتين ، ليس من الواضح كيفية البحث عن مناطق المشكلة. لذلك ، توصلنا إلى مقياسنا الخاص وأطلقنا عليه اسم "ابن آوى".

لقد ألهمتنا الصورة القديمة. اعتبرنا أننا نعين لكل تطبيق منفَّذ عدد آوى ، وكيف يكون مملاً ومملًا ولا نريد القيام بذلك. في نهاية الشهر ، أخذوا في الاعتبار التطبيقات التي سجلها ابن آوى أكثر.

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

المرحلة التالية ، حيث وجدنا طرق الأتمتة ، هي الروبوتات. لقد أتقننا واجهة برمجة تطبيقات Telegram ، وبدأنا في قطع برامج التتبُّع للجميع على التوالي ، خصوصًا لأنفسنا. انتهينا من المشغلات الأخيرة.



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

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

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

العمل مع DEV

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

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

Artem: من وجهة نظر CI ، هذا كله مهم للغاية. في موازاة ذلك ، أنا أعمل كمستفيد من المنتج وأدير المشاريع وقيادة فرق التطوير. وهنا حالة مثيرة جدا للاهتمام.

في الفرق الصغيرة ، قمنا بدمج وظائف العملية ، أي Stage و Prod في نفس الوحدة. في هذه المشاريع الصغيرة ، والمنتجات الصغيرة ، والفرق والبنى التحتية ، اتضح أن هذا الأمر مريح للغاية. ترى حقًا كيف ستدير المعركة.

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



ما الذي جاء منه؟ هنا ، يقول الكثيرون أنه لا يوجد قسم DevOps ، نعتقد أن لدينا قسم DevOps. ما هي المهام الرئيسية للقسم؟

يمشي ، يروج ، يتحدث عن DevOps. الجميع يفهم ما هو وكيفية طهيه. يخبرون ويظهرون كيف يمكن طرح منتج جديد بقاعدة بيانات في خمس دقائق.

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

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



سيرجي:سأتحدث عن الألم. نحن ندعم خطة استرداد DRP من البداية. وعندما لم يكن هناك أتمتة ، قمنا بنسخ التكوينات هناك تقريبًا. تمت إضافة وحدات جديدة باستمرار ، ويجب تحديث الخطة باستمرار. مع ظهور DevOps والأتمتة ، تقلصت الخطة: نأخذ أحدث إصدار حالي من Git ونضيف خططًا إليه.

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

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

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

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

كان المكان الوحيد الذي بقي فيه وكان عمره ساعتان على الأقل هو هجرة مخططات المعالجة المركزية. الآن يستغرق الأمر ثماني دقائق.



سيرجي: على الشريحة مستند جديد ، تطبيق من سطر واحد: دمج في بوابة. لم يعد هناك تلك الأوراق A4 العشرة.

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



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

أرتيم: واجهت أسئلة من السلطات: "أرتيم ، متى DevOps؟" قال أنه لن يكون هناك موعد نهائي ، نحاول في برود ، لا تطلب أي شيء.

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

Artem: هنا أنا مقتنع بأن القمة لا يمكن إجبارها على تنفيذ DevOps. هذا غير واقعي لمثل هذا المشروع.



سيرجي: لقد حللنا أين نفقد معظم وقتنا: واليوم نفقد معظم وقتنا على الأمن.

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

Artem: على سبيل المثال ، يمكنك استخدام Merge لهذا ، انظر ما تغير في الوصفة. حارس الأمن هو أيضا مهندس.

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

من وجهة نظر OPS ، لا تزال لدينا مشكلة إضاعة الوقت على CI وتعديل الوصفات. هذا الشيء بدأ بالفعل في كسب "ابن آوى". لذلك ، ننظر إلى الأنظمة لتقديم أطر عمل للمطورين ، ونتطلع إلى Docker ، Kubernetes ، حتى نتمكن من الكتابة: "يا شباب ، هناك أدوات ، ولا توجد مستندات كبيرة ، يمكنك توحيد عملية التسليم."

نريد تطوير هذه الفكرة ، لكن الأمن يقاوم مرة أخرى. يقولون: "ما نوع الشبكات الافتراضية التي لديك ، كيف ستسير هذه الخدمات بدون جدار حماية؟" هناك بعض التناقضات ، ولكن أعتقد أننا سنفوز على أي حال.

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

من الصعب إلقاء اللوم على المدقق ، فهو يقوم بالعمل على أساس المعايير التي تنص على أن الأجهزة المادية يجب أن تكون آلة منفصلة وغير افتراضية. لا حاويات.

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

أحتاج إلى معرفة كيفية إنشاء صورة لوجود الشركة بهذه الكلمات الرهيبة حتى يكون كل شيء صحيحًا وصادقًا.

إذا كنت تعبت من القراءات الطويلة - نوصي بالاستماع إلى إصدار بودكاست "Five Minute PHP" مع أصدقائنا Baruch Sadogursky و Vyacheslav Kuznetsov. Trends DevOps و DecSecOps وانتصار Kubernetes وتقرير State of DevOps 2018 من DORA.

وإذا كنت تريد المزيد من التقارير الرائعة ، فانتقل إلى مؤتمر DevOops 2018. سيكون هناك Baruch و Glory وحتى John Willis ! جميع المتحدثين والبرنامج على الموقع .

مكافأة لطيفة: حتى 1 أكتوبر ، يمكن حجز تذكرة لـ DevOops 2018 بخصم .