تحدث أنطون فايس، مؤسس ومدير شركة Otomato Software، أحد المبادرين والمدربين لأول شهادة DevOps في إسرائيل، في مؤتمر العام الماضي حول نظرية الفوضى والمبادئ الرئيسية لهندسة الفوضى، وشرح أيضًا كيفية عمل تنظيم DevOps المثالي للمستقبل.
لقد قمنا بإعداد نسخة نصية من التقرير.
صباح الخير!
DevOpsDays في موسكو للعام الثاني على التوالي، هذه هي المرة الثانية التي أتواجد فيها على هذه المرحلة، والعديد منكم موجود في هذه الغرفة للمرة الثانية. ماذا يعني ذلك؟ وهذا يعني أن حركة DevOps في روسيا تنمو وتتضاعف، والأهم من ذلك أنه حان الوقت للحديث عن ماهية DevOps في عام 2018.
ارفعوا أيديكم من يعتقد أن DevOps أصبحت بالفعل مهنة في عام 2018؟ هناك مثل هذا. هل يوجد أي من مهندسي DevOps في الغرفة الذين يشير وصفهم الوظيفي إلى "مهندس DevOps"؟ هل هناك أي مديرين DevOps في الغرفة؟ لايوجد مثيل. المهندسين المعماريين DevOps؟ أيضا لا. ليس كافي. هل صحيح حقًا أنه لا أحد يقول إنه مهندس DevOps؟
لذا يعتقد معظمكم أن هذا نمط مضاد؟ أن مثل هذه المهنة لا ينبغي أن تكون موجودة؟ يمكننا أن نفكر في ما نريد، ولكن بينما نفكر، تتقدم الصناعة رسميًا للأمام على صوت بوق DevOps.
مين سمع عن موضوع جديد اسمه DevDevOps؟ هذه تقنية جديدة تسمح بالتعاون الفعال بين المطورين والمطورين. وليس جديدا جدا. إذا حكمنا من خلال تويتر، فقد بدأوا بالفعل الحديث عن هذا منذ 4 سنوات. وحتى الآن الاهتمام بهذا يتزايد وينمو، أي أن هناك مشكلة. المشكلة تحتاج إلى حل.
نحن أشخاص مبدعون، ولا نرتاح فحسب. نقول: DevOps ليست كلمة شاملة بما فيه الكفاية، فهي لا تزال تفتقر إلى جميع أنواع العناصر المختلفة والمثيرة للاهتمام. ونذهب إلى مختبراتنا السرية ونبدأ في إنتاج طفرات مثيرة للاهتمام: DevTestOps، وGitOps، وDevSecOps، وBizDevOps، وProdOps.
المنطق صارم، أليس كذلك؟ نظام التسليم لدينا لا يعمل، وأنظمتنا غير مستقرة ومستخدمونا غير راضين، وليس لدينا الوقت لطرح البرامج في الوقت المحدد، ولا نتناسب مع الميزانية. كيف سنحل كل هذا؟ سنأتي بكلمة جديدة! سينتهي بـ "Ops" ويتم حل المشكلة.
لذلك أسمي هذا النهج "عمليات، وتم حل المشكلة".
كل هذا يتلاشى في الخلفية إذا ذكّرنا أنفسنا لماذا توصلنا إلى كل هذا. لقد توصلنا إلى فكرة DevOps بأكملها لجعل تسليم البرامج وعملنا في هذه العملية دون عوائق، وغير مؤلم، وفعال، والأهم من ذلك، ممتع قدر الإمكان.
نشأت DevOps من الألم. وتعبنا من المعاناة. ولكي يحدث كل هذا، نعتمد على ممارسات دائمة الخضرة: التعاون الفعال، وممارسات التدفق، والأهم من ذلك، التفكير المنظومي، لأنه بدونه لن تعمل DevOps.
ما هو النظام؟
وإذا كنا نتحدث بالفعل عن التفكير المنظومي، فلنذكر أنفسنا ما هو النظام.
إذا كنت من القراصنة الثوريين، فمن الواضح أن النظام شرير بالنسبة لك. إنها سحابة تخيم عليك وتجبرك على القيام بأشياء لا تريد القيام بها.
من وجهة نظر التفكير النظمي، النظام هو كل يتكون من أجزاء. وبهذا المعنى، كل واحد منا هو نظام. المنظمات التي نعمل فيها هي أنظمة. وما نبنيه أنا وأنت يسمى نظامًا.
كل هذا جزء من نظام اجتماعي وتكنولوجي كبير. وفقط إذا فهمنا كيف يعمل هذا النظام الاجتماعي التكنولوجي معًا، فعندها فقط سنكون قادرين على تحسين شيء ما حقًا في هذا الشأن.
من منظور التفكير النظمي، يتمتع النظام بالعديد من الخصائص المثيرة للاهتمام. أولا، يتكون من أجزاء، مما يعني أن سلوكه يعتمد على سلوك الأجزاء. علاوة على ذلك، فإن جميع أجزائه مترابطة أيضًا. لقد اتضح أنه كلما زاد عدد أجزاء النظام، زادت صعوبة فهم سلوكه أو التنبؤ به.
من وجهة نظر سلوكية، هناك حقيقة أخرى مثيرة للاهتمام. يمكن للنظام أن يفعل شيئًا لا يستطيع أي من أجزائه الفردية القيام به.
وكما قال الدكتور راسل أكوف (أحد مؤسسي التفكير المنظومي)، فمن السهل إثبات ذلك من خلال تجربة فكرية. على سبيل المثال، من في الغرفة يعرف كيفية كتابة التعليمات البرمجية؟ هناك الكثير من الأيدي، وهذا أمر طبيعي، لأن هذا هو أحد المتطلبات الرئيسية لمهنتنا. هل تعرف كيف تكتب، ولكن هل يمكن أن تكتب يديك التعليمات البرمجية بشكل منفصل عنك؟ هناك أشخاص سيقولون: "ليست يدي هي التي تكتب الكود، بل عقلي هو الذي يكتب الكود." هل يمكن لعقلك كتابة التعليمات البرمجية بشكل منفصل عنك؟ حسنا، ربما لا.
الدماغ آلة مذهلة، فنحن لا نعرف حتى 10% من كيفية عمله هناك، لكنه لا يستطيع أن يعمل بشكل منفصل عن النظام الذي هو جسمنا. ومن السهل إثبات ذلك: افتح جمجمتك، وأخرج دماغك، وضعه أمام الكمبيوتر، ودعه يحاول كتابة شيء بسيط. "مرحبا بالعالم" في بايثون، على سبيل المثال.
إذا كان النظام يستطيع القيام بشيء لا يستطيع أي من أجزائه القيام به بشكل منفصل، فهذا يعني أن سلوكه لا يتحدد من خلال سلوك أجزائه. ما الذي يحدده إذن؟ يتم تحديده من خلال التفاعل بين هذه الأجزاء. وبناءً على ذلك، كلما زاد عدد الأجزاء، زادت تعقيد التفاعلات، وأصبح من الصعب فهم سلوك النظام والتنبؤ به. وهذا يجعل مثل هذا النظام فوضويًا، لأن أي تغيير غير مرئي، حتى غير مهم، في أي جزء من النظام يمكن أن يؤدي إلى نتائج غير متوقعة تمامًا.
تم اكتشاف هذه الحساسية للظروف الأولية ودراستها لأول مرة من قبل عالم الأرصاد الجوية الأمريكي إد لورينز. وسمي فيما بعد بـ”تأثير الفراشة” وأدى إلى تطور حركة فكرية علمية تسمى “نظرية الفوضى”. أصبحت هذه النظرية واحدة من التحولات النموذجية الرئيسية في العلوم في القرن العشرين.
نظرية الفوضى
الأشخاص الذين يدرسون الفوضى يطلقون على أنفسهم علماء الفوضى.
في الواقع، كان السبب وراء هذا التقرير هو أنني، من خلال العمل مع أنظمة موزعة معقدة ومنظمات دولية كبيرة، أدركت في مرحلة ما أن هذا هو ما أشعر به. أنا عالم الفوضى. هذه في الأساس طريقة ذكية للقول: "أنا لا أفهم ما يحدث هنا ولا أعرف ماذا أفعل حيال ذلك".
أعتقد أن الكثير منكم غالبًا ما يشعر بهذه الطريقة، لذا أنتم أيضًا علماء فوضى. أدعوك إلى نقابة علماء الفوضى. إن الأنظمة التي سندرسها أنا وأنت، زملائي علماء الفوضى الأعزاء، تسمى "الأنظمة التكيفية المعقدة".
ما هي القدرة على التكيف؟ تعني القدرة على التكيف أن السلوك الفردي والجماعي للأجزاء في مثل هذا النظام التكيفي يتغير وينظم ذاتيًا، ويستجيب للأحداث أو سلاسل الأحداث الصغيرة في النظام. أي أن النظام يتكيف مع التغيرات من خلال التنظيم الذاتي. وتعتمد هذه القدرة على التنظيم الذاتي على التعاون الطوعي اللامركزي تمامًا بين الوكلاء المستقلين الأحرار.
خاصية أخرى مثيرة للاهتمام لهذه الأنظمة هي أنها قابلة للتطوير بحرية. ما يجب أن يثير اهتمامنا بلا شك كمهندسين علماء الفوضى. لذا، إذا قلنا أن سلوك النظام المعقد يتحدد من خلال تفاعل أجزائه، فما الذي يجب أن نهتم به؟ تفاعل.
هناك نوعان من النتائج الأكثر إثارة للاهتمام.
أولاً، نحن نفهم أنه لا يمكن تبسيط النظام المعقد عن طريق تبسيط أجزائه. ثانيًا، الطريقة الوحيدة لتبسيط نظام معقد هي تبسيط التفاعلات بين أجزائه.
كيف نتفاعل؟ أنت وأنا جميعنا أجزاء من نظام معلومات كبير يسمى المجتمع البشري. نحن نتفاعل من خلال لغة مشتركة، إذا كانت لدينا، إذا وجدناها.
لكن اللغة نفسها هي نظام تكيفي معقد. وفقا لذلك، من أجل التفاعل بشكل أكثر كفاءة وبساطة، نحتاج إلى إنشاء نوع من البروتوكولات. أي تسلسل معين من الرموز والإجراءات التي من شأنها أن تجعل تبادل المعلومات بيننا أسهل وأكثر قابلية للتنبؤ به وأكثر قابلية للفهم.
أريد أن أقول إن الاتجاهات نحو التعقيد، نحو القدرة على التكيف، نحو اللامركزية، نحو الفوضى يمكن تتبعها في كل شيء. وفي الأنظمة التي نبنيها أنا وأنت، وفي تلك الأنظمة التي نحن جزء منها.
ولكي لا نكون بلا أساس، دعونا ننظر إلى كيفية تغير الأنظمة التي ننشئها.
كنت تنتظر هذه الكلمة، وأنا أفهم. نحن في مؤتمر DevOps، اليوم سنسمع هذه الكلمة حوالي مائة ألف مرة وبعدها سنحلم بها ليلاً.
الخدمات الصغيرة هي أول بنية برمجية ظهرت كرد فعل لممارسات DevOps، والتي تم تصميمها لجعل أنظمتنا أكثر مرونة وقابلة للتطوير وضمان التسليم المستمر. كيف أنها لم تفعل هذا؟ من خلال تقليل حجم الخدمات، وتقليل نطاق المشكلات التي تعالجها هذه الخدمات، وتقليل وقت التسليم. أي أننا نقوم بتقليل أجزاء النظام وتبسيطها، وزيادة عددها، وبالتالي يزيد دائمًا تعقيد التفاعلات بين هذه الأجزاء، أي تظهر مشكلات جديدة يتعين علينا حلها.
الخدمات الصغيرة ليست النهاية، الخدمات الصغيرة بشكل عام كانت بالأمس بالفعل، لأن Serverless قادم. جميع الخوادم احترقت، لا توجد خوادم، ولا أنظمة تشغيل، فقط تعليمات برمجية قابلة للتنفيذ. التكوينات منفصلة، والدول منفصلة، وكل شيء تسيطر عليه الأحداث. الجمال، النظافة، الصمت، لا أحداث، لا شيء يحدث، نظام كامل.
أين هو التعقيد؟ الصعوبة بالطبع تكمن في التفاعلات. إلى أي مدى يمكن لوظيفة واحدة أن تفعل بمفردها؟ وكيف يتفاعل مع الوظائف الأخرى؟ قوائم انتظار الرسائل وقواعد البيانات والموازنات. كيفية إعادة إنشاء بعض الأحداث عند حدوث فشل؟ أسئلة كثيرة وإجابات قليلة.
الخدمات المصغرة و Serverless هي ما نسميه محبو موسيقى الجاز المهووسون Cloud Native. الأمر كله يتعلق بالسحابة. لكن السحابة أيضًا محدودة بطبيعتها في قابليتها للتوسع. لقد اعتدنا على التفكير فيه كنظام موزع. في الواقع، أين تعيش خوادم موفري الخدمات السحابية؟ في مراكز البيانات. وهذا يعني أن لدينا هنا نوعًا من النموذج المركزي والمحدود للغاية والموزع.
نحن ندرك اليوم أن إنترنت الأشياء لم يعد مجرد كلمات كبيرة، فحتى وفقًا لتوقعات متواضعة، تنتظرنا مليارات الأجهزة المتصلة بالإنترنت في السنوات الخمس إلى العشر القادمة. كمية هائلة من البيانات المفيدة وغير المفيدة التي سيتم دمجها في السحابة وتحميلها من السحابة.
لن تدوم السحابة، لذلك نحن نتحدث بشكل متزايد عن شيء يسمى الحوسبة المتطورة. أو يعجبني أيضًا التعريف الرائع لـ "حوسبة الضباب". إنه يكتنفه التصوف من الرومانسية والغموض.
حوسبة الضباب. النقطة المهمة هي أن السحب عبارة عن كتل مركزية من الماء والبخار والجليد والحجارة. والضباب عبارة عن قطرات من الماء تتطاير حولنا في الغلاف الجوي.
في نموذج الضباب، يتم تنفيذ معظم العمل بواسطة هذه القطرات بشكل مستقل تمامًا أو بالتعاون مع قطيرات أخرى. ولا يلجأون إلى السحابة إلا عندما يتعرضون لضغوط شديدة.
وهذا هو، مرة أخرى، اللامركزية، والاستقلالية، وبالطبع، الكثير منكم يفهم بالفعل إلى أين يتجه كل هذا، لأنه لا يمكنك التحدث عن اللامركزية دون ذكر blockchain.
هناك من يصدق، وهؤلاء هم من استثمروا في العملات المشفرة. هناك من يؤمن ولكن يخاف مثلي مثلا. وهناك من لا يؤمن. هنا يمكنك التعامل بشكل مختلف. هناك تكنولوجيا، أمر جديد غير معروف، هناك مشاكل. مثل أي تكنولوجيا جديدة، فإنها تثير أسئلة أكثر مما تجيب.
الضجيج حول blockchain أمر مفهوم. وبعيداً عن الاندفاع نحو الذهب، فإن التكنولوجيا ذاتها تحمل وعوداً رائعة بمستقبل أكثر إشراقاً: المزيد من الحرية، والمزيد من الاستقلالية، والثقة العالمية الموزعة. ما الذي لا تريده؟
وبناءً على ذلك، بدأ المزيد والمزيد من المهندسين حول العالم في تطوير التطبيقات اللامركزية. وهذه قوة لا يمكن تجاهلها بمجرد القول: "آه، بلوكتشين هي مجرد قاعدة بيانات موزعة سيئة التنفيذ". أو كما يحب المتشككون أن يقولوا: "لا توجد تطبيقات حقيقية لتقنية البلوكشين". إذا فكرت في الأمر، فقبل 150 عامًا قالوا نفس الشيء عن الكهرباء. بل وكانوا على حق في بعض النواحي، لأن ما جعلته الكهرباء ممكنا اليوم لم يكن ممكنا بأي حال من الأحوال في القرن التاسع عشر.
بالمناسبة، من يعرف ما هو نوع الشعار الذي يظهر على الشاشة؟ هذا هو هايبرليدجر. هذا مشروع يتم تطويره تحت رعاية مؤسسة Linux ويتضمن مجموعة من تقنيات blockchain. هذه هي حقًا قوة مجتمعنا مفتوح المصدر.
هندسة الفوضى
لذا، فإن النظام الذي نقوم بتطويره أصبح أكثر تعقيدًا، وأكثر فوضوية، وأكثر تكيفًا. تعد Netflix رائدة في أنظمة الخدمات الصغيرة. وكانوا من أول من فهم ذلك، فطوروا مجموعة من الأدوات أطلقوا عليها اسم الجيش القردي، وأشهرها هو . وحدد ما أصبح يعرف باسم .
بالمناسبة، في عملية العمل على التقرير، قمنا حتى بترجمة هذا النص إلى اللغة الروسية، لذلك انتقل إلى ، اقرأ، علق، أنب.
باختصار، تقول مبادئ هندسة الفوضى ما يلي. الأنظمة الموزعة المعقدة بطبيعتها لا يمكن التنبؤ بها وعربات التي تجرها الدواب بطبيعتها. الأخطاء أمر لا مفر منه، مما يعني أننا بحاجة إلى قبول هذه الأخطاء والعمل مع هذه الأنظمة بطريقة مختلفة تمامًا.
يجب علينا نحن أنفسنا أن نحاول إدخال هذه الأخطاء في أنظمة الإنتاج لدينا من أجل اختبار أنظمتنا لنفس القدرة على التكيف، هذه القدرة ذاتها على التنظيم الذاتي، من أجل البقاء.
وهذا يغير كل شيء. ليس فقط كيفية إطلاق الأنظمة في الإنتاج، ولكن أيضًا كيفية تطويرها، وكيف نختبرها. لا توجد عملية تثبيت أو تجميد للكود، بل على العكس، هناك عملية مستمرة من زعزعة الاستقرار. نحن نحاول قتل النظام ورؤيته يستمر في البقاء.
بروتوكولات تكامل النظام الموزع
وبناء على ذلك، فإن هذا يتطلب أن تتغير أنظمتنا بطريقة أو بأخرى. ولكي تصبح أكثر استقرارًا، فإنها تحتاج إلى بعض البروتوكولات الجديدة للتفاعل بين أجزائها. حتى تتمكن هذه الأجزاء من الاتفاق والتوصل إلى نوع من التنظيم الذاتي. وتظهر جميع أنواع الأدوات الجديدة والبروتوكولات الجديدة، والتي أسميها "بروتوكولات تفاعل الأنظمة الموزعة".
ما الذي أتحدث عنه؟ أولا، المشروع . يحاول البعض إنشاء بروتوكول تتبع موزع عام، وهو أداة لا غنى عنها تمامًا لتصحيح أخطاء الأنظمة الموزعة المعقدة.
إضافي - . نقول أننا لا نستطيع التنبؤ بما سيحدث للنظام، أي أننا بحاجة إلى زيادة إمكانية ملاحظته، وقابليته للملاحظة. ينتمي Opentracing إلى مجموعة من الأدوات التي توفر إمكانية المراقبة لأنظمتنا. لكننا نحتاج إلى إمكانية الملاحظة من أجل تحديد ما إذا كان النظام يتصرف كما نتوقعه أم لا. كيف نحدد السلوك المتوقع؟ من خلال تحديد نوع ما من السياسة، مجموعة من القواعد. يعمل مشروع وكيل السياسة المفتوحة على تحديد هذه المجموعة من القواعد عبر نطاق يتراوح من الوصول إلى تخصيص الموارد.
كما قلنا، أصبحت أنظمتنا تعتمد على الأحداث بشكل متزايد. يعد Serverless مثالًا رائعًا للأنظمة التي تعتمد على الأحداث. لكي نتمكن من نقل الأحداث بين الأنظمة وتتبعها، نحتاج إلى لغة مشتركة، وبعض البروتوكولات المشتركة لكيفية التحدث عن الأحداث، وكيف ننقلها لبعضنا البعض. وهذا ما يسمى المشروع .
إن التدفق المستمر للتغييرات التي تغمر أنظمتنا، والتي تزعزع استقرارها باستمرار، هو تيار مستمر من المصنوعات البرمجية. لكي نتمكن من الحفاظ على هذا التدفق المستمر للتغييرات، نحتاج إلى نوع من البروتوكول المشترك الذي يمكننا من خلاله التحدث عن ماهية البرنامج، وكيف يتم اختباره، وما هو التحقق الذي تم اجتيازه. وهذا ما يسمى المشروع . أي بروتوكول بيانات وصفية شائع للعناصر البرمجية.
وأخيرًا، إذا أردنا أن تكون أنظمتنا مستقلة تمامًا، ومتكيفة، ومنظمة ذاتيًا، فيجب أن نمنحها الحق في تحديد هويتها الذاتية. مشروع يسمى هذا هو بالضبط ما يفعله. وهذا أيضًا مشروع تحت رعاية مؤسسة Cloud Native Computing Foundation.
كل هذه المشاريع شابة، وكلها تحتاج إلى حبنا وموافقتنا. كل هذا مفتوح المصدر، واختبارنا، وتنفيذنا. أنها تبين لنا أين تتجه التكنولوجيا.
لكن DevOps لم تكن تتعلق بالتكنولوجيا في المقام الأول، بل كانت دائمًا تتعلق بالتعاون بين الأشخاص. وبناء على ذلك، إذا أردنا أن تتغير الأنظمة التي نطورها، فيجب علينا أن نتغير بأنفسنا. في الواقع، نحن نتغير على أي حال، وليس لدينا الكثير من الخيارات.
هناك رائع الكاتبة البريطانية راشيل بوتسمان، والتي تكتب فيها عن تطور الثقة عبر تاريخ البشرية. وتقول إنه في البداية، في المجتمعات البدائية، كانت الثقة محلية، أي أننا كنا نثق فقط بمن نعرفهم شخصيًا.
ثم كانت هناك فترة طويلة للغاية - وقت مظلم عندما كانت الثقة مركزية، عندما بدأنا نثق في الأشخاص الذين لا نعرفهم على أساس حقيقة أننا ننتمي إلى نفس المؤسسة العامة أو الدولة.
وهذا ما نراه في عالمنا الحديث: الثقة أصبحت موزعة ولامركزية بشكل متزايد، وهي مبنية على حرية تدفق المعلومات، وعلى توافر المعلومات.
إذا فكرت في الأمر، فإن إمكانية الوصول هذه، التي تجعل هذه الثقة ممكنة، هي ما نقوم بتنفيذه أنا وأنت. وهذا يعني أن الطريقة التي نتعاون بها والطريقة التي نقوم بها بها يجب أن تتغير، لأن مؤسسات تكنولوجيا المعلومات المركزية الهرمية القديمة لم تعد تعمل. يبدأون في الموت.
أساسيات منظمة DevOps
إن منظمة DevOps المثالية للمستقبل هي نظام لا مركزي وقابل للتكيف يتكون من فرق مستقلة، يتكون كل منها من أفراد مستقلين. وتنتشر هذه الفرق في جميع أنحاء العالم، وتتعاون بشكل فعال مع بعضها البعض باستخدام الاتصالات غير المتزامنة، وذلك باستخدام بروتوكولات اتصال عالية الشفافية. جميلة جدا، أليس كذلك؟ مستقبل جميل جدا .
وبطبيعة الحال، لا شيء من هذا ممكن من دون التغيير الثقافي. يجب أن تكون لدينا قيادة تحويلية، ومسؤولية شخصية، ودافع داخلي.
هذا هو أساس منظمات DevOps: شفافية المعلومات، والاتصالات غير المتزامنة، والقيادة التحويلية، واللامركزية.
الانطلاق
إن الأنظمة التي نحن جزء منها وتلك التي نبنيها تزداد فوضوية، ومن الصعب علينا نحن البشر أن نتعامل مع هذا الفكر، ومن الصعب أن نتخلى عن وهم السيطرة. نحاول الاستمرار في السيطرة عليهم، وهذا غالبًا ما يؤدي إلى الإرهاق. أقول هذا من تجربتي الخاصة، لقد تعرضت للحرق أيضًا، كما تم إعاقتي بسبب إخفاقات غير متوقعة في الإنتاج.
يحدث الإرهاق عندما نحاول السيطرة على شيء لا يمكن السيطرة عليه بطبيعته. عندما نحترق، يفقد كل شيء معناه لأننا نفقد الرغبة في القيام بشيء جديد، ونصبح دفاعيين ونبدأ بالدفاع عما لدينا.
إن مهنة الهندسة، كما أحب أن أذكر نفسي في كثير من الأحيان، هي في المقام الأول مهنة إبداعية. إذا فقدنا الرغبة في خلق شيء ما، فإننا نتحول إلى رماد، نتحول إلى رماد. يحترق الناس، وتحترق المنظمات بأكملها.
في رأيي، فقط قبول القوة الخلاقة للفوضى، وبناء التعاون وفق مبادئها فقط هو ما سيساعدنا على عدم فقدان ما هو جيد في مهنتنا.
وهذا ما أتمناه لك: أن تحب عملك، وأن تحب ما نقوم به. هذا العالم يتغذى على المعلومات، ولدينا شرف تغذيته. لذلك دعونا ندرس الفوضى، دعونا نكون علماء الفوضى، دعونا نحقق القيمة، ونخلق شيئًا جديدًا، حسنًا، المشاكل، كما اكتشفنا بالفعل، لا مفر منها، وعندما تظهر، سنقول ببساطة "عمليات!" ويتم حل المشكلة.
ماذا بخلاف قرد الفوضى؟
في الواقع، كل هذه الأدوات حديثة جدًا. قامت نفس أدوات Netflix ببناء أدوات لأنفسهم. بناء الأدوات الخاصة بك. اقرأ مبادئ هندسة الفوضى وطبق تلك المبادئ بدلاً من محاولة العثور على أدوات أخرى أنشأها شخص آخر بالفعل.
حاول أن تفهم كيف تتعطل أنظمتك وابدأ في تفكيكها وانظر كيف تصمد. هذا يأتي أولا. ويمكنك البحث عن الأدوات. هناك جميع أنواع المشاريع.
لم أفهم تمامًا اللحظة التي قلت فيها أنه لا يمكن تبسيط النظام من خلال تبسيط مكوناته، وانتقلت على الفور إلى الخدمات الصغيرة، التي تعمل على تبسيط النظام من خلال تبسيط المكونات نفسها وتعقيد التفاعلات. هذان هما في الأساس جزأين يتناقضان مع بعضهما البعض.
هذا صحيح، الخدمات المصغرة هي موضوع مثير للجدل للغاية بشكل عام. في الواقع، تبسيط الأجزاء يزيد من المرونة. ماذا تقدم الخدمات المصغرة؟ إنها تمنحنا المرونة والسرعة، لكنها بالتأكيد لا تمنحنا البساطة. يزيدون من الصعوبة.
إذن، في فلسفة DevOps، الخدمات الصغيرة ليست شيئًا جيدًا؟
أي خير له جانب عكسي. والفائدة هي أنها تزيد من المرونة، مما يسمح لنا بإجراء تغييرات بشكل أسرع، ولكنها تزيد من تعقيد النظام بأكمله وبالتالي هشاشةه.
ومع ذلك، ما الذي يجب التركيز عليه أكثر: على تبسيط التفاعل أم على تبسيط الأجزاء؟
ينصب التركيز بالطبع على تبسيط التفاعلات، لأنه إذا نظرنا إلى هذا من وجهة نظر كيفية عملنا معك، فإننا نحتاج أولاً إلى الاهتمام بتبسيط التفاعلات، وليس تبسيط العمل. لكل واحد منا على حدة. لأن تبسيط العمل يعني التحول إلى روبوتات. هنا في ماكدونالدز، يعمل الأمر بشكل طبيعي عندما يكون لديك تعليمات: هنا تضع البرجر، وهنا تصب الصلصة عليه. وهذا لا ينطبق على الإطلاق في عملنا الإبداعي.
هل صحيح أن كل ما قلته يعيش في عالم بلا منافسة، والفوضى هناك لطيفة للغاية، ولا توجد تناقضات داخل هذه الفوضى، فلا أحد يريد أن يأكل أو يقتل أحداً؟ كيف ينبغي أن تكون المنافسة و DevOps؟
حسنًا، يعتمد الأمر على نوع المنافسة التي نتحدث عنها. هل يتعلق الأمر بالمنافسة في مكان العمل أم المنافسة بين الشركات؟
عن منافسة الخدمات الموجودة لأن الخدمات ليست عدة شركات. نحن نخلق بيئة معلوماتية من نوع جديد، ولا يمكن لأي بيئة أن تعيش بدون منافسة. هناك منافسة في كل مكان.
نفس Netflix، نأخذهم كنموذج يحتذى به. لماذا توصلوا إلى هذا؟ لأنهم بحاجة إلى أن يكونوا قادرين على المنافسة. إن هذه المرونة وسرعة الحركة هي على وجه التحديد المتطلب التنافسي للغاية، فهي تسبب الفوضى في أنظمتنا. أي أن الفوضى ليست شيئًا نفعله بوعي لأننا نريده، بل هي شيء يحدث لأن العالم يطلب ذلك. علينا فقط أن نتكيف. والفوضى هي على وجه التحديد نتيجة المنافسة.
هل يعني هذا أن الفوضى هي غياب الأهداف كما كانت؟ أو تلك الأهداف التي لا نريد رؤيتها؟ نحن في المنزل ولا نفهم أهداف الآخرين. المنافسة، في الواقع، ترجع إلى حقيقة أن لدينا أهدافًا واضحة ونعلم أين سننتهي في كل لحظة تالية من الزمن. وهذا، من وجهة نظري، هو جوهر DevOps.
أيضا نظرة على السؤال. أعتقد أن لدينا جميعًا نفس الهدف: البقاء على قيد الحياة والقيام بذلك
أعظم متعة. والهدف التنافسي لأي منظمة هو نفسه. غالبًا ما يحدث البقاء على قيد الحياة من خلال المنافسة، ولا يمكنك فعل أي شيء حيال ذلك.
مؤتمر هذا العام سيقام يوم 7 ديسمبر في تكنوبوليس. نحن نقبل طلبات التقارير حتى 11 نوفمبر. لنا إذا كنت ترغب في التحدث.
التسجيل للمشاركين مفتوح، وتكلفة التذاكر 7000 روبل. انضم إلينا!
المصدر: www.habr.com