تعريف DevOps معقد للغاية ، لذلك عليك أن تبدأ المناقشة حوله مرة أخرى في كل مرة. فقط في حبري يوجد ألف منشور حول هذا الموضوع. ولكن إذا كنت تقرأ هذا ، فمن المحتمل أنك تعرف ما هو DevOps. لأنني لست كذلك. مرحبا اسمي الكسندر تيتوف (@) وسنتحدث فقط عن DevOps وسأشارك تجربتي.
فكرت لفترة طويلة في كيفية جعل قصتي مفيدة ، لذلك سيكون هناك العديد من الأسئلة هنا - تلك التي أطرحها على نفسي ، وتلك التي أطرحها على عملاء شركتنا. بالإجابة على هذه الأسئلة ، يصبح الفهم أفضل. سأخبرك لماذا هناك حاجة إلى DevOps من وجهة نظري ، وما هي ، مرة أخرى ، من وجهة نظري ، وكيف أفهم أنك تتجه نحو DevOps مرة أخرى من وجهة نظري. ستكون النقطة الأخيرة من خلال الأسئلة. من خلال الإجابة عليها لنفسك ، يمكنك فهم ما إذا كانت شركتك تتجه نحو DevOps أو ما إذا كانت هناك مشاكل بطريقة ما.
ذات مرة مشيت في موجات الاندماج والاستحواذ. أولاً ، عملت في شركة صغيرة تسمى Qik ، ثم تم شراؤها من قبل شركة أكبر قليلاً ، Skype ، والتي تم شراؤها لاحقًا من قبل شركة أكبر قليلاً ، Microsoft. في تلك اللحظة ، أصبحت رؤية متاحة لي عن كيفية تحول فكرة DevOps في شركات ذات أحجام مختلفة. بعد ذلك ، أصبح من المثير للاهتمام بالنسبة لي أن ألقي نظرة على DevOps من وجهة نظر السوق ، وقمت أنا وزملائي بتنظيم شركة Express 42. لمدة 6 سنوات كنا نتحرك على طول موجات السوق.
من بين أمور أخرى ، أنا أحد منظمي مجتمع DevOps Moscow ومنظم DevOps -Days 2017 ، لكنني لم أنظم 2018. يعمل Express 42 مع العديد من الشركات. نحن ننمي DevOps هناك ، ونشاهد كيف يحدث ذلك ، ونستخلص النتائج ، ونحلل ، ونخبر الجميع بالنتائج التي توصلنا إليها ، وندرب الناس على ممارسات DevOps. بشكل عام ، نقوم بكل الطرق الممكنة بتنمية الخبرة والخبرة بهذا المعنى.
لماذا DevOps
السؤال الأول الذي يطارد الجميع ودائما - لماذا؟ يعتقد الكثير من الناس أن DevOps هو مجرد أتمتة أو شيء مشابه تمتلكه كل شركة بالفعل.
- كان لدينا تكامل مستمر - وهذا يعني أن لدينا بالفعل DevOps ، ولماذا نحتاج إلى كل هذه القمم؟ إنهم يستمتعون بالخارج ، لكنهم يتدخلون في عملنا!
لمدة 9 سنوات من تطوير المجتمع والمنهجية ، أصبح من الواضح بالفعل أن هذا لا يزال ليس بريقًا تسويقيًا ، ولكن لا يزال من غير الواضح تمامًا سبب الحاجة إليه. مثل أي أداة وعملية ، تمتلك DevOps أهدافًا محددة تحققها في النهاية.
كل هذا يرجع إلى حقيقة أن العالم يتغير. إنه يبتعد عن نهج المؤسسة ، عندما تنتقل الشركات مباشرة إلى الحلم ، كما غنت كلاسيكينا الكلاسيكي في سانت بطرسبرغ ، من النقطة أ إلى النقطة ب وفقًا لاستراتيجية معينة ، مع هيكل معين مبني لهذا الغرض.
من حيث المبدأ ، يجب بناء كل شيء في تكنولوجيا المعلومات وفقًا لهذا النهج. هنا يتم استخدام تكنولوجيا المعلومات حصريًا لأتمتة العمليات.
لا تتغير الأتمتة في كثير من الأحيان ، لأنه عندما تتدحرج شركة ما في طريق متهالك - ما الذي يمكن تغييره؟ إنه يعمل ، لا تلمسه. الآن تتغير المناهج في العالم ، وتلك التي تسمى كلمة Agile تقول أن نقطة النهاية B ليست مرئية على الفور.
عندما تمر شركة ما في السوق ، وتعمل مع عميل ، فإنها تستكشف السوق باستمرار وتغير نقطة النهاية ب. علاوة على ذلك ، كلما غيرت الشركة اتجاهها في كثير من الأحيان ، كانت أكثر نجاحًا في النهاية ، لأنها تختار المزيد من السوق منافذ.
تم عرض الاستراتيجية من خلال شركة مثيرة للاهتمام تعرفت عليها مؤخرًا. One Box Shave هي خدمة توصيل لماكينات الحلاقة وإكسسوارات الحلاقة عن طريق الاشتراك في علبة. إنهم يعرفون كيفية تخصيص "الصندوق" الخاص بهم لعملاء مختلفين. يتم ذلك عن طريق برنامج معين ، والذي يقوم بعد ذلك بإرسال الطلب إلى المصنع الكوري الذي ينتج البضائع.
اشترت شركة Unilever هذا المنتج مقابل مليار دولار. وهي الآن تتنافس مع شركة Gillette وقد تسببت في تآكل حصة كبيرة من المستهلكين في السوق الأمريكية. يقول One Box Shave:
- 4 ريش؟ هل أنت جاد؟ لماذا تحتاجه - فهو لا يحسن جودة الحلاقة. الكريم المختار خصيصًا والعطر وشفرة الحلاقة عالية الجودة ذات الشفرتين تحل مشاكل أكثر بكثير من شفرات جيليت الأربعة الغبية! قريبًا سوف نصل إلى 4؟
لذا فإن العالم يتغير. تدعي شركة Unilever أن لديها نظامًا رائعًا لتكنولوجيا المعلومات يتيح لها القيام بذلك. في النهاية يبدو وكأنه مفهوم حان وقت التسوق، التي لم يتحدث عنها أحد بالفعل.
لا يتعلق الوقت المستغرق في السوق بعدد المرات التي ننتشر فيها. يمكنك غالبًا النشر ، لكن دورات الإصدار ستكون طويلة. إذا كانت دورات الإصدار التي تبلغ مدتها ثلاثة أشهر متراكبة على بعضها البعض ، وتتغير لمدة أسبوع ، فقد اتضح أن الشركة تنشر على ما يبدو مرة واحدة في الأسبوع. يستغرق الأمر 3 أشهر من الفكرة إلى التنفيذ النهائي.
يتعلق الوقت المستغرق في السوق بتقليل الوقت من الفكرة إلى التنفيذ النهائي.
في هذه الحالة ، يتفاعل البرنامج مع السوق. هذه هي الطريقة التي يتفاعل بها موقع One Box Shave مع العميل. ليس لديهم بائعون - مجرد موقع ينقر فيه الزائر ويترك رغباته. وبناءً على ذلك ، يجب أن ينشر الموقع باستمرار شيئًا جديدًا ، وتحديثه وفقًا للرغبات. على سبيل المثال ، في كوريا الجنوبية يحلقون بشكل مختلف عن روسيا ، ولا يحبون رائحة الصنوبر في العطر ، ولكن ، على سبيل المثال ، جزر الفانيليا.
نظرًا لأن محتوى الموقع يحتاج إلى التغيير بسرعة ، فإن تطوير البرامج يتغير كثيرًا. من خلال البرنامج ، يجب أن نعرف ما يريده العميل. في السابق ، تعلمنا هذا من خلال بعض الحلول ، على سبيل المثال ، من خلال إدارة الأعمال. ثم قمنا بالتصميم ووضع المتطلبات في نظام تكنولوجيا المعلومات ، وكان كل شيء رائعًا. الأمر مختلف الآن - تم تصميم البرنامج بواسطة كل من يشارك في العملية ، بما في ذلك المهندسين ، لأنهم يتعلمون كيفية عمل السوق من خلال المواصفات الفنية وأيضًا مشاركة أفكارهم مع الأعمال.
على سبيل المثال ، في Qik ، اكتشفنا فجأة أن الأشخاص يحبون حقًا تحميل قوائم جهات الاتصال على الخادم ، ووضعوا لنا تطبيقًا. في البداية ، لم نفكر في الأمر. في شركة كلاسيكية ، قد يقرر الجميع أن هذا خطأ ، نظرًا لأن المواصفات لا تنص على أنه يجب أن يعمل بشكل جيد وتم تنفيذه بشكل عام على الركبة ، فسيوقفون الميزة ويقولون: "لا أحد يحتاج هذا ، أكثر من الشيء المهم هو أن الوظيفة الرئيسية تعمل ". وترى شركة التكنولوجيا فرصة في ذلك وتبدأ في تغيير البرنامج وفقًا لذلك.
في عام 1968 ، صاغ الرجل صاحب الرؤية ملفين كونواي الفكرة التالية.
المنظمة التي تنشئ نظامًا مقيدة بتصميم يكرر بنية الاتصال في تلك المنظمة.
بمزيد من التفصيل ، من أجل إنتاج أنظمة من نوع مختلف ، يجب أن يكون لدى المرء أيضًا هيكل اتصال داخل شركة من نوع مختلف. إذا كانت بنية الاتصال الخاصة بك ذات تسلسل هرمي عالي ، فلن يسمح لك ذلك بإنشاء أنظمة يمكنها توفير وقت وصول إلى السوق مرتفع للغاية.
شرف يمكن للمرء . من المهم فهم ثقافة أو فلسفة DevOps ، مثل الشيء الوحيد الذي يتغير بشكل أساسي في DevOps هو بنية الاتصال بين الفرق.
من حيث العملية ، قبل DevOps ، كانت جميع المراحل: التحليلات ، والتطوير ، والاختبار ، والتشغيل ، تتم بشكل خطي.
في حالة DevOps ، تستمر كل هذه العمليات في وقت واحد.
الوقت اللازم للتسويق هو الطريقة الوحيدة للقيام بذلك. بالنسبة للأشخاص الذين عملوا في العملية القديمة ، يبدو الأمر كونيًا بعض الشيء ، وبشكل عام كذلك.
فلماذا نحتاج إلى DevOps؟
لتطوير المنتجات الرقمية. إذا لم يكن لدى شركتك منتج رقمي ، فلن تكون هناك حاجة إلى DevOps - وهذا أمر مهم للغاية.
تتغلب DevOps على حدود السرعة لإنتاج البرامج التسلسلية. في ذلك ، تحدث جميع العمليات في وقت واحد.
الصعوبة آخذة في الازدياد. عندما يقول دعاة DevOps أنه سيسهل عليك إصدار البرامج ، فهذا هراء.
مع DevOps ، ستصبح الأمور أكثر صعوبة.
في المؤتمر في كشك Avito ، يمكنك أن ترى ما يعنيه نشر حاوية Docker - وهي مهمة غير واقعية. يصبح التعقيد باهظًا ، عليك التوفيق بين العديد من الكرات في نفس الوقت.
تقوم DevOps بتغيير العملية والتنظيم في الشركة تمامًا - بتعبير أدق ، لا يتغير DevOps ، ولكنه منتج رقمي. للقدوم إلى DevOps ، ما زلت بحاجة إلى تغيير هذه العملية بالكامل.
أسئلة لمتخصص
ماذا لديك؟ أسئلة يمكنك طرحها على نفسك أثناء العمل في شركة والتطور كمتخصص.
هل لديك إستراتيجية لإنشاء منتج رقمي؟ إذا كان هناك ، فهذا جيد. هذا يعني أن شركتك تتجه نحو DevOps.
هل تقوم شركتك بالفعل بإنشاء منتج رقمي؟ هذا يعني أنه يمكنك الصعود خطوة واحدة إلى الأعلى ، والقيام بأشياء أكثر إثارة للاهتمام - من وجهة نظر DevOps مرة أخرى. أنا أتحدث فقط من وجهة النظر هذه.
هل شركتك من رواد السوق في مجال المنتجات الرقمية؟ Spotify و Yandex و Uber هي شركات في ذروة التقدم التكنولوجي الآن.
اسأل نفسك هذه الأسئلة ، وإذا كانت جميع الإجابات بالنفي ، فربما لا ينبغي عليك تنفيذ DevOps في هذه الشركة. إذا كنت مهتمًا حقًا بـ DevOps ، فربما ... هل يجب عليك الانتقال إلى شركة أخرى؟ إذا كانت شركتك تريد الانتقال إلى DevOps ، لكنك أجبت بـ "لا" على جميع الأسئلة ، فهي مثل وحيد القرن الجميل هذا الذي لن يتغير أبدًا.
منظمة
كما قلت ، وفقًا لقانون كونواي ، تتغير المنظمة في الشركة. بادئ ذي بدء ، ما يمنع DevOps من اختراق داخل الشركة هو من وجهة نظر المنظمة.
مشكلة "الآبار"
تتم ترجمة الكلمة الإنجليزية "Silo" هنا إلى الروسية باسم "well". الهدف من هذه المشكلة هو أن لا يوجد تبادل للمعلومات بين الفرق. يقوم كل فريق بحفر خبرته بعمق ، بينما لا يقوم ببناء خريطة مشتركة للتنقل فيها.
من بعض النواحي ، هذا يذكرنا بشخص وصل لتوه إلى موسكو ولا يزال لا يعرف كيفية التنقل في خريطة المترو. عادة ما يعرف سكان موسكو منطقتهم جيدًا ، وفي جميع أنحاء موسكو يسترشدون بخريطة المترو. عندما تأتي إلى موسكو لأول مرة ، لا تملك هذه المهارة وتشعر بالارتباك.
تقترح DevOps المرور بهذه اللحظة من الارتباك وإنشاء خريطة تفاعل مشتركة لجميع الأقسام معًا.
هناك عاملان يعيقان ذلك.
نتيجة نظام إدارة الشركات. تم بناؤه بواسطة "آبار" هرمية منفصلة. على سبيل المثال ، هناك بعض مؤشرات الأداء الرئيسية في الشركات التي تدعم هذا النظام. من ناحية أخرى ، تتدخل أدمغة الشخص الذي يجد صعوبة في تجاوز خبراته والتنقل في النظام بأكمله. إنه فقط غير مريح. تخيل أنك في مطار بانكوك - لن تجد اتجاهاتك هناك بسرعة. يصعب التنقل في DevOps أيضًا ، وهذا هو السبب في أن الناس يقولون إن عليك العثور على دليل للوصول إلى هناك.
ولكن الشيء الأكثر أهمية هو أن مشكلة "الآبار" بالنسبة للمهندس المشبع بروح DevOps ، وقراءة فاولر ومجموعة من الكتب الأخرى ، يتم التعبير عنها في حقيقة أن "الآبار" لا تسمح لك بعمل أشياء "واضحة". غالبًا ما نجتمع معًا بعد DevOps Moscow ، ونتحدث مع بعضنا البعض ، ويشكو الناس:
- أردنا فقط إطلاق CI ، لكن اتضح أن الإدارة لم تكن بحاجة إليه.
يحدث هذا على وجه التحديد لأن CI и عملية التسليم المستمر على حدود العديد من الخبرات. فقط بدون التغلب على مشكلة "الآبار" على المستوى التنظيمي ، لن تكون قادرًا على المضي قدمًا ، بغض النظر عما تفعله وبغض النظر عن مدى حزنها.
كل مشارك في العملية في الشركة: مطورو الواجهة الخلفية والواجهة ، والاختبار ، و DBA ، والتشغيل ، والشبكة ، والحفر في اتجاههم الخاص ، ولا يوجد أحد لديه خريطة مشتركة ، باستثناء المدير ، الذي يشرف عليهم بطريقة ما ويدير "التقسيم" وقهر "الطريقة.
الناس يقاتلون من أجل نوع من النجوم أو الأعلام ، الجميع يحفرون خبراتهم الخاصة.
نتيجة لذلك ، عندما تنشأ المهمة لربط كل هذا معًا وبناء خط أنابيب مشترك ، ولا توجد حاجة للقتال من أجل العلامات النجمية والأعلام ، فإن السؤال الذي يطرح نفسه - ماذا تفعل بشكل عام؟ نحن بحاجة إلى التفاوض بطريقة ما ، لكن لم يعلمنا أحد في المدرسة كيفية القيام بذلك. لقد تعلمنا منذ المدرسة: الصف الثامن - واو! مقارنة بالصف السابع! إنه نفس الشيء هنا.
هل هو نفسه في شركتك؟
لاختبار ذلك ، يمكنك أن تسأل نفسك الأسئلة التالية.
هل تستخدم الفرق أدوات مشتركة وتساهم في التغييرات في هذه الأدوات المشتركة؟
كم مرة يتم إعادة تشكيل الفرق - ينتقل بعض المتخصصين من فريق إلى فريق آخر؟ يصبح هذا أمرًا طبيعيًا في بيئة DevOps ، لأنه في بعض الأحيان لا يستطيع الشخص ببساطة فهم ما يفعله مجال آخر من مجالات الخبرة. ينتقل إلى قسم آخر ، ويعمل هناك لمدة أسبوعين ليصنع لنفسه خريطة للتوجيه والتفاعل مع هذا القسم.
هل من الممكن تشكيل لجنة تغيير وتغيير شيء ما؟ أم أن هذا يتطلب يدًا قوية من القيادة العليا ونظامًا؟ لقد كتبت مؤخرًا على Facebook كيف أن بنكًا غير معروف يقوم بتنفيذ الأدوات من خلال الأوامر: لقد كتبنا أمرًا ، ونقوم بتنفيذه لمدة عام ، وننظر إلى ما يحدث. هذا بالطبع طويل ومحزن.
ما مدى أهمية تلقي المديرين للإنجازات الشخصية دون مراعاة إنجازات الشركة؟
إذا أجبت على هذه الأسئلة بنفسك ، فسيكون من الواضح ما إذا كان لديك مثل هذه المشكلة في الشركة.
البنية التحتية كرمز
بعد تجاوز هذه المشكلة ، فإن أول ممارسة مهمة ، والتي بدونها يصعب المضي قدمًا في DevOps ، هي البنية التحتية كرمز.
في أغلب الأحيان ، يُنظر إلى البنية التحتية كرمز على النحو التالي:
- لنقم بأتمتة كل شيء في bash ، ونغطي أنفسنا بالنصوص بحيث يكون للمسؤولين عمل يدوي أقل!
لكنها ليست كذلك.
تعني البنية التحتية كرمز أنك تصف نظام تكنولوجيا المعلومات الذي تعمل به في شكل رمز من أجل فهم حالته باستمرار.
بالتعاون مع الفرق الأخرى ، تقوم بإنشاء خريطة في شكل رمز يمكن للجميع فهمه ، والذي يمكنك من خلاله التنقل والتنقل. لا يهم ما يتم إجراؤه على - Chef أو Ansible أو Salt أو استخدام ملفات YAML في Kubernetes - لا يهم.
في المؤتمر ، أخبر زميل من 2GIS كيف قاموا بصنع شيء داخلي خاص بهم لـ Kubernetes ، والذي يصف هيكل الأنظمة الفردية. لوصف 500 نظام ، احتاجوا إلى أداة منفصلة تولد هذا الوصف. عندما يكون هناك هذا الوصف ، يمكن للجميع التحقق من بعضهم البعض ، ومراقبة التغييرات ، وكيفية تغييرها وتحسينها ، وما هو مفقود.
موافق ، نصوص bash الفردية عادة لا تعطي هذا الفهم. في إحدى الشركات التي أعمل فيها ، كان هناك اسم "اكتب فقط" - نص - عند كتابة السيناريو ، لكن لم يعد من الممكن قراءته. أعتقد أن هذا مألوف لك أيضًا.
البنية التحتية كما هو رمز رمز يصف الحالة الحالية للبنية التحتية. تعمل العديد من فرق المنتجات والبنية التحتية والخدمة معًا على هذا الرمز ، والأهم من ذلك كله أنهم بحاجة إلى فهم كيفية عمل هذا الرمز بشكل عام.
يتم الحفاظ على الكود وفقًا لأفضل ممارسات الترميز: التطوير التعاوني ، ومراجعات الكود ، وبرمجة XP ، والاختبار ، وطلبات السحب ، و CI للبنى التحتية للكود - كل هذا جيد وقابل للاستخدام.
تصبح الكود هي اللغة المشتركة لجميع المهندسين.
لا يستغرق تغيير البنية التحتية في الكود الكثير من الوقت. نعم ، يمكن أن يكون لقانون البنية التحتية أيضًا ديون فنية. عادة ، تواجه الفرق ذلك بعد عام ونصف من بدء تنفيذ "البنية التحتية ككود" في شكل مجموعة من البرامج النصية أو حتى Ansible ، والتي يكتبونها مثل كود السباغيتي ، ويرمون نصوص باش في الأعلى!
من المهم: إذا لم تكن قد جربت هذه القمامة ، فتذكر ذلك أنسبل ليس باش! اقرأ الوثائق بعناية ، وادرس ما يكتبون عنه بشكل عام.
البنية التحتية كرمز هي تقسيم كود البنية التحتية إلى طبقات منفصلة.
في شركتنا ، نميز 3 طبقات أساسية ، وهي واضحة وبسيطة للغاية ، ولكن يمكن أن يكون هناك المزيد. يمكنك إلقاء نظرة على رمز البنية التحتية الخاصة بك ومعرفة ما إذا كان لديك هذا الشرط أم لا. إذا لم يتم تحديد طبقات ، فأنت بحاجة إلى قضاء بعض الوقت وإعادة البناء قليلاً.
طبقة القاعدة - هذه هي الطريقة التي يتم بها تكوين نظام التشغيل والنسخ الاحتياطية والأشياء الأخرى منخفضة المستوى ، على سبيل المثال ، كيفية نشر Kubernetes على المستوى الأساسي.
طبقة الخدمة - هذه هي الخدمات التي تقدمها للمطور: التسجيل كخدمة ، المراقبة كخدمة ، قاعدة البيانات كخدمة ، الموازن كخدمة ، قائمة الانتظار كخدمة ، التسليم المستمر كخدمة - مجموعة من الخدمات التي تقدمها الفرق الفردية يمكن أن تقدم للتنمية. كل هذا يحتاج إلى وصفه بواسطة وحدات منفصلة في نظام إدارة التكوين الخاص بك.
طبقة حيث يتم عمل التطبيقات ويصف كيف سيتم فتحهما فوق الطبقتين السابقتين.
أسئلة التحكم
هل لديك مستودع بنية تحتية مشترك في شركتك؟ هل تتحكم في الديون الفنية للبنية التحتية؟ هل تستخدم ممارسات التطوير في مستودع البنية التحتية؟ هل البنية التحتية الخاصة بك مقسمة إلى طبقات؟ يمكنك الرجوع إلى مخطط Base-service-APP. ما مدى صعوبة إجراء التغيير؟
إذا كنت قد جربت أن الأمر استغرق يومًا ونصفًا لإجراء التغييرات ، فهذا يعني أن لديك دينًا تقنيًا وتحتاج إلى التعامل معه. لقد عثرت للتو على أشعل النار من الديون التقنية في كود البنية التحتية. أتذكر العديد من هذه القصص ، عندما تريد تغيير بعض CCTL ، تحتاج إلى إعادة كتابة نصف رمز البنية التحتية ، لأن الإبداع والرغبة في أتمتة كل شيء أدى إلى حقيقة أن كل شيء يتم التنصت عليه في كل مكان ، وإزالة جميع المقابض ، وتحتاج إلى لإعادة البناء.
العرض المستمر
دعنا نقارن الخصم بالائتمان. يأتي أولاً وصف البنية التحتية ، والذي يمكن أن يكون أساسيًا تمامًا. ليس من الضروري وصف كل شيء بالتفصيل ، لكن بعض الوصف الأساسي مطلوب حتى تتمكن من التعامل معه. خلاف ذلك ، ليس من الواضح على رأس ما ينبغي القيام به مزيد من التسليم المستمر. تتكشف كل هذه الممارسات في نفس الوقت الذي تأتي فيه إلى DevOps ، ولكن عليك أن تبدأ بفهم ما لديك وكيفية إدارته. هذه مجرد ممارسة للبنية التحتية كرمز.
بعد أن أصبح من الواضح أن لديك كيفية إدارته ، تبدأ في معرفة كيفية إرسال رمز المطور إلى الإنتاج في أسرع وقت ممكن. أعني مع المطور - نتذكر مشكلة "الآبار" ، أي أنه لا يأتي الأفراد بهذا ، بل الفريق.
عندما نكون مع فانيا إفتوخوفيتش رأى الكتاب الأول جيزا متواضع ومجموعات المؤلفين "التسليم المستمر"، الذي تم إصداره في عام 2009 ، فكرنا لفترة طويلة في كيفية ترجمة اسمه إلى اللغة الروسية. لقد أرادوا ترجمته كـ "تقديم مستمر" ، لكن للأسف قاموا بترجمته على أنه "إمداد مستمر". يبدو لي أنه يوجد باسمنا شيئًا روسيًا للغاية ، مع الضغط.
توفير الوسائل باستمرار
يمكن دائمًا طرح الكود الموجود في مستودع المنتج للإنتاج. قد لا يتم ضخه ، لكنه مستعد دائمًا لذلك. وفقًا لذلك ، فأنت تكتب دائمًا رمزًا بشعور يصعب شرحه ببعض القلق تحت العصعص. يظهر غالبًا عند طرح رمز البنية التحتية. يجب أن يكون هذا الشعور بعدم الارتياح حاضرًا - فهو يطلق عمليات الدماغ التي تسمح لك بكتابة التعليمات البرمجية بشكل مختلف قليلاً. يجب أن يتم إصلاح ذلك في القواعد داخل التطوير.
لتقديم متسق ، تحتاج إلى تنسيق قطعة أثرية يجتاز منصة البنية التحتية. إذا ألقيت "نفايات الحياة" عبر منصة بنية تحتية بأشكال مختلفة ، فإنها تصبح موحدة ، ويصعب صيانتها ، وتظهر مشكلة الدين الفني. يجب أن يكون تنسيق القطعة الأثرية متناسقًا - وهذه أيضًا مهمة جماعية: نحتاج جميعًا إلى الالتقاء معًا ، وحفيف أدمغتنا والتوصل إلى هذا التنسيق.
يتم تحسين الأداة وتغييرها باستمرار لتلائم بيئة الإنتاج أثناء تحركها عبر خط أنابيب التسليم. عندما تتحرك قطعة أثرية على طول خط الأنابيب ، فإنها تواجه باستمرار بعض الأشياء غير الملائمة لها ، والتي تشبه ما تواجهه الأداة التي تضعها في الإنتاج. إذا تم ذلك في التطوير الكلاسيكي بواسطة مسؤول النظام الذي يتم طرحه ، فسيحدث هذا في عملية DevOps طوال الوقت: هنا قاموا بلفها ببعض الاختبارات ، ثم قاموا بإلقائها في مجموعة Kubernetes ، والتي تشبه إلى حد ما الإنتاج ، ثم أطلقوا فجأة اختبار الحمل.
هذا يذكرنا إلى حد ما بلعبة Pacman - فالقطعة الأثرية تمر بنوع من القصة. في الوقت نفسه ، من المهم التحكم فيما إذا كانت الشفرة تمر بالفعل عبر التاريخ وما إذا كانت مرتبطة بطريقة ما بإنتاجك. يمكن سحب القصص من الإنتاج إلى داخل عملية التسليم المستمر: كان الأمر هكذا عندما سقط شيء ما ، فلنقم الآن ببرمجة هذا السيناريو داخل النظام. في كل مرة يمر فيها الرمز بهذا السيناريو أيضًا ، ولن تواجه هذه المشكلة في المرة القادمة. ستعرف عنها في وقت أبكر بكثير مما تذهب إلى عميلك.
استراتيجيات نشر مختلفة. على سبيل المثال ، يمكنك استخدام اختبار AB أو عمليات نشر الكناري "لتشعر" بالرمز بشكل مختلف على عملاء مختلفين ، والحصول على معلومات حول كيفية عمل الكود ، وقبل ذلك بكثير عندما يتم طرحه على 100 مليون مستخدم.
تبدو عبارة "تقديم باستمرار" على هذا النحو.
إن عملية توصيل Dev و CI و Test و PreProd و Prod ليست بيئة منفصلة ، فهذه مراحل أو محطات بكميات مقاومة للحريق تمر عبرها القطع الأثرية الخاصة بك.
إذا كان لديك رمز البنية التحتية الموصوف باسم Base Service APP ، فإنه يساعد لا تنسى كل النصوص، وكتابتها كرمز لهذه القطعة الأثرية أيضًا ، الترويج لقطعة أثرية وقم بتغييره كما تذهب.
أسئلة الاختبار الذاتي
هل الوقت من وصف الميزة إلى طرحها للإنتاج أقل من أسبوع في 95٪ من الحالات؟ هل تزداد جودة القطع الأثرية في كل مرحلة من مراحل خط الأنابيب؟ هل هناك قصة يتابعها؟ هل تستخدم استراتيجيات نشر مختلفة؟
إذا كانت جميع الإجابات بنعم ، فأنت رائع بشكل غير واقعي! اكتب الإجابات في التعليقات - سأكون سعيدًا).
ردود الفعل
هذه هي أصعب ممارسة على الإطلاق. في مؤتمر DevOpsConf ، كان أحد الزملاء من Infobip ، يتحدث عنه ، مرتبكًا بعض الشيء في الكلمات ، لأن هذه ممارسة صعبة للغاية حول حقيقة أنك بحاجة إلى مراقبة كل شيء بشكل عام!
على سبيل المثال ، منذ وقت طويل ، عندما عملت في Qik وأدركنا أننا بحاجة إلى مراقبة كل شيء بشكل عام. لقد فعلنا ذلك ، ولدينا 150 عنصر في Zabbix ، تتم مراقبتها باستمرار. كان الأمر مخيفًا ، قام المدير الفني بلف إصبعه في صدغه:
- رفاق ، لماذا تغتصب الخادم لسبب غير معروف؟
ولكن بعد ذلك وقع حادث أظهر أن هذه استراتيجية رائعة حقًا.
بدأت إحدى الخدمات في الانخفاض باستمرار. في البداية ، لم يتعطل ، وهو أمر مثير للاهتمام ، لم تتم إضافة الكود هناك ، لأنه كان وسيطًا أساسيًا لم يكن فيه عمليا أي وظائف تجارية - لقد أرسل فقط رسائل بين خدمات منفصلة. لم تتغير الخدمة لمدة 4 أشهر ، وفجأة بدأت في الانهيار مع ظهور خطأ "خطأ في التجزئة".
لقد صدمنا ، فتحنا مخططاتنا في Zabbix ، واتضح أنه ، منذ أسبوع ونصف ، تغير سلوك الطلبات في خدمة API التي يستخدمها هذا الوسيط كثيرًا. بعد ذلك ، رأينا أن تكرار إرسال نوع معين من الرسائل قد تغير. بعد أن اكتشفنا أن هؤلاء هم عملاء android. سألنا:
- رفاق ، ماذا حدث لكم منذ أسبوع ونصف؟
رداً على ذلك ، سمعوا قصة مثيرة للاهتمام بأنهم أعادوا تصميم واجهة المستخدم. من غير المحتمل أن يقول أي شخص على الفور أنه قام بتغيير مكتبة HTTP. بالنسبة لعملاء Android ، فإن الأمر يشبه تغيير الصابون في الحمام - فهم لا يتذكرونه. نتيجة لذلك ، بعد 40 دقيقة من المحادثة ، اكتشفنا أنهم قاموا بتغيير مكتبة HTTP ، وتغير توقيتها الافتراضي. أدى ذلك إلى حقيقة أن سلوك المرور على خادم واجهة برمجة التطبيقات (API) قد تغير ، مما أدى إلى موقف تسبب في حدوث سباق داخل الوسيط ، وبدأ في الانخفاض.
بدون مراقبة عميقة ، من المستحيل فتحه على الإطلاق.. إذا كانت المنظمة لا تزال تعاني من مشكلة "الآبار" ، فعندما يرمي الجميع على بعضهم البعض ، يمكن أن يعيش هذا لسنوات. ما عليك سوى إعادة تشغيل الخادم لأنه لا توجد طريقة لإصلاح المشكلة. عندما تراقب كل الأحداث التي لديك وتتبعها وتتبعها ، وتستخدم المراقبة كاختبار - اكتب رمزًا ووضح على الفور كيفية مراقبته ، وأيضًا في شكل رمز (لدينا بالفعل البنية التحتية كرمز) ، يصبح كل شيء واضحًا مثل على راحة اليد. حتى هذه المشاكل المعقدة يمكن تعقبها بسهولة.
اجمع كل المعلومات حول ما يحدث مع الأداة في كل مرحلة من مراحل عملية التسليم - وليس في الإنتاج.
مراقبة الحمل على CI ، وستكون بعض الأشياء الأساسية مرئية بالفعل هناك. ثم ستراها في الاختبار وفي PredProd وفي اختبار الحمل. جمع المعلومات في جميع المراحل ، وليس فقط المقاييس والإحصاءات ، ولكن أيضًا السجلات: كيف تم طرح التطبيق ، والأشكال الشاذة - اجمع كل شيء.
خلاف ذلك ، سيكون من الصعب فهمه. لقد قلت بالفعل أن DevOps أكثر تعقيدًا. للتعامل مع هذا التعقيد ، يجب أن يكون لديك تحليلات عادية.
أسئلة لضبط النفس
هل أداة المراقبة والتسجيل الخاصة بك هي أداة التطوير بالنسبة لك؟ هل يفكر مطوروك ، بمن فيهم أنت ، عندما يكتبون التعليمات البرمجية ، في كيفية مراقبتها؟
هل تسمع عن مشاكل من العملاء؟ هل تفهم العميل بشكل أفضل من المراقبة والتسجيل؟ هل تفهم النظام بشكل أفضل من المراقبة والتسجيل؟ هل غيرت النظام لمجرد أنك رأيت أن الاتجاه في النظام ينمو وتدرك أن 3 أسابيع أخرى وكل شيء سيموت؟
بمجرد الانتهاء من وضع هذه المكونات الثلاثة ، يمكنك التفكير في نوع منصة البنية التحتية التي تمتلكها في شركتك.
منصة البنية التحتية
ليس المقصود أن هذه مجموعة من الأدوات المتباينة التي تمتلكها كل شركة.
الهدف من منصة البنية التحتية هو أن جميع الفرق تستخدم هذه الأدوات وتطورها معًا.
من الواضح أن هناك فرقًا منفصلة مسؤولة عن تطوير الأجزاء الفردية لمنصة البنية التحتية. ولكن في الوقت نفسه ، يكون كل مهندس مسؤولاً عن تطوير منصة البنية التحتية وأدائها وتعزيزها. على المستوى الداخلي ، تصبح أداة شائعة.
تقوم جميع الفرق بتطوير منصة البنية التحتية ، وتعاملها بعناية كما لو كانت IDE خاصة بهم. في IDE الخاص بك ، تقوم بتثبيت مكونات إضافية مختلفة لجعل كل شيء لطيفًا وسريعًا ، وإعداد مفاتيح الاختصار. عندما تفتح Sublime أو Atom أو Visual Studio Code ، يكون لديك أخطاء في التعليمات البرمجية تتدفق هناك وتدرك أنه من المستحيل العمل على الإطلاق ، تشعر بالحزن على الفور وتجري إصلاح IDE الخاص بك.
تعامل مع منصة البنية التحتية الخاصة بك بنفس الطريقة. إذا فهمت أن هناك شيئًا ما خطأ فيه ، فاترك طلبًا إذا لم تتمكن من إصلاحه بنفسك. إذا كان هناك شيء بسيط - قم بتحريره بنفسك ، أرسل طلب سحب - يفكر الرجال في الإضافة. هذا نهج مختلف قليلاً لمجموعة الأدوات الهندسية في رأس المطور.
تضمن منصة البنية التحتية نقل الأداة من التطوير إلى العميل مع التحسين المستمر للجودة. تمت برمجة واجهة المستخدم بمجموعة من القصص التي تحدث للترميز في الإنتاج. على مدار سنوات التطوير ، أصبحت هذه القصص كثيرة جدًا ، بعضها فريد من نوعه ولا ينطبق إلا عليك - لا يمكن البحث عنها في Google.
في هذه المرحلة ، تصبح منصة البنية التحتية هي ميزتك التنافسية.، لأنه يحتوي على شيء غير موجود في أداة المنافس. كلما كان عنوان IP الخاص بك أعمق ، زادت ميزتك التنافسية من حيث الوقت للوصول إلى السوق. يظهر هنا مشكلة قفل البائع: يمكنك استخدام منصة شخص آخر ، ولكن باستخدام تجربة شخص آخر ، لن تفهم مدى ملاءمتها لك. نعم ، لا تستطيع كل شركة بناء منصة شبيهة بالأمازون. هذا خط صعب حيث تكون تجربة الشركة ذات صلة بمكانتها في السوق ، ولا يمكن تحرير قفل البائع هناك. هذا مهم أيضًا للتفكير فيه.
القيادة
هذا مخطط أساسي لمنصة بنية تحتية ستساعدك في إعداد جميع الممارسات والعمليات في شركة DevOps.
دعونا نرى ما يتكون منه.
نظام تنسيق الموارد، والذي يوفر وحدة المعالجة المركزية والذاكرة والقرص للتطبيقات والخدمات الأخرى. علاوة على ذلك - خدمات منخفضة المستوى: المراقبة ، التسجيل ، محرك CI / CD ، تخزين القطع الأثرية ، البنية التحتية كرمز للنظام.
خدمات ذات مستوى أعلى: قاعدة البيانات كخدمة ، قوائم الانتظار كخدمة ، موازنة التحميل كخدمة ، تغيير حجم الصورة كخدمة ، مصنع البيانات الكبيرة كخدمة. علاوة على ذلك - خط الأنابيب الذي يقدم تعليمات برمجية معدلة باستمرار إلى عميلك.
تحصل على معلومات حول كيفية عمل برنامجك مع العميل ، وتغييره ، وتسليم هذا الرمز مرة أخرى ، والحصول على المعلومات - وهكذا تقوم باستمرار بتطوير كل من منصة البنية التحتية والبرامج الخاصة بك.
في المخطط ، يتكون خط أنابيب التسليم من عدة مراحل. لكن هذا رسم تخطيطي ، تم تقديمه كمثال - لست بحاجة إلى تكراره واحدًا تلو الآخر. تتفاعل المراحل مع الخدمات كما هو الحال مع الخدمات - كل لبنة في النظام الأساسي لها قصتها الخاصة: كيفية تخصيص الموارد ، وكيفية إطلاق التطبيق ، والعمل مع الموارد ، والمراقبة ، والتغييرات.
من المهم أن نفهم أن كل جزء من المنصة يحمل قصة ، واسأل نفسك عن القصة التي تحملها هذه القطعة ، ربما يجب التخلص منها واستبدالها بخدمة طرف ثالث. على سبيل المثال ، هل من الممكن وضع Okmeter بدلاً من الطوب؟ ربما قام الرجال بالفعل بضخ هذه الخبرة أكثر مما نفعل. لكن ربما لا - ربما لدينا خبرة فريدة ، نحتاج إلى تثبيت بروميثيوس وتطويره بشكل أكبر.
إنشاء المنصة
هذه عملية اتصال معقدة. عندما يكون لديك ممارسات أساسية ، فإنك تبدأ في التواصل بين مختلف المهندسين والمتخصصين الذين يطورون المتطلبات والمعايير ، ويغيرونها باستمرار إلى أدوات وأساليب مختلفة. الثقافة التي تتمتع بها DevOps مهمة هنا.
مع الثقافة ، كل شيء بسيط للغاية - هو التعاون والتواصل، أي الرغبة في العمل في مجال مشترك مع بعضنا البعض ، والرغبة في امتلاك آلة واحدة معًا. لا يوجد علم الصواريخ هنا - كل شيء بسيط للغاية ، مبتذل. على سبيل المثال ، نعيش جميعًا في المدخل ونحافظ عليه نظيفًا - مثل هذا المستوى من الثقافة.
ماذا لديك؟
مرة أخرى ، يمكنك طرح الأسئلة على نفسك.
هل توجد منصة بنية تحتية مخصصة؟ من المسؤول عن تطويره؟ هل تفهم المزايا التنافسية لمنصة البنية التحتية الخاصة بك؟
هذه هي الأسئلة التي يجب أن تطرحها على نفسك طوال الوقت. إذا كان من الممكن نقل شيء ما إلى خدمات الجهات الخارجية ، فأنت بحاجة إلى إزالته ؛ إذا بدأت خدمة تابعة لجهة خارجية في حظر حركتك ، فأنت بحاجة إلى بناء نظام داخل نفسك.
لذا DevOps ...
... هذا نظام معقد ، يجب أن يحتوي على:
- منتج رقمي.
- وحدات الأعمال التي تطور هذا المنتج الرقمي.
- فرق المنتج التي تكتب الرمز.
- ممارسات التسليم المستمر.
- المنصات كخدمة.
- البنية التحتية كخدمة.
- البنية التحتية كرمز.
- ممارسات الموثوقية المنفصلة داخل DevOps.
- ممارسة التغذية الراجعة التي تصف كل شيء.
يمكنك استخدام هذا المخطط عن طريق تلوين ما لديك بالفعل في شركتك بشكل ما: تم تطويره أو لا يزال بحاجة إلى التطوير.
سوف تختفي في غضون أسبوعين . كجزء من RIT ++. تعال إلى المؤتمر ، حيث ستجد الكثير من المحادثات الرائعة حول التسليم المستمر والبنية التحتية مثل الكود وتحويل DevOps. ، آخر موعد للسعر 20 مايو
المصدر: www.habr.com