تحدث مؤسس ومدير Otomato Software ، أحد المبادرين والمدربين لأول شهادة لإسرائيل DevOps ، أنطون فايس ، عن نظرية الفوضى والمبادئ الأساسية للهندسة الفوضوية في
DevOpsDays Moscow العام الماضي ، وشرح أيضًا كيف تعمل منظمة DevOps المثالية للمستقبل.
أعددنا نسخة نصية من التقرير.
صباح الخير
DevOpsDays في موسكو للسنة الثانية على التوالي ، أنا المرة الثانية في هذه المرحلة ، العديد منكم هي المرة الثانية في هذه الغرفة. ماذا يعني هذا؟ هذا يعني أن حركة DevOps في روسيا تنمو وتتضاعف ، والأهم من ذلك ، فهذا يعني أن الوقت قد حان للحديث عن ماهية DevOps في عام 2018.
رفع يديك أولئك الذين يعتقدون أن DevOps في عام 2018 هو بالفعل مهنة؟ هناك بعض. هل هناك مهندسو DevOps في الغرفة قاموا بكتابة "DevOps engineer" في الوصف الوظيفي؟ هل هناك مدراء DevOps في الغرفة؟ لا يوجد شيء. DevOps المهندسين المعماريين؟ لا كذلك. ليس كافي ما ، حقا ، لم يكتب أحد أنه مهندس DevOps؟
لذلك معظمكم يعتقدون أن هذا هو مضاد لل؟ ما لا ينبغي أن يكون مثل هذه المهنة؟ يمكننا أن نفكر في أي شيء ، لكن في الوقت الحالي نعتقد أن الصناعة تتقدم رسميًا إلى أصوات أنبوب DevOps.
من سمع عن موضوع جديد يسمى DevDevOps؟ هذا هو أسلوب جديد ، والذي يسمح بالتعاون الفعال بين المطورين و devops. وليست جديدة إذا حكمنا على تويتر ، منذ 4 سنوات بدأوا يتحدثون عنه. وما زال الاهتمام بهذا ينمو ويتزايد ، فهناك مشكلة. يجب حل المشكلة.
نحن أناس مبدعون ، لذلك لا تهدأ. نقول: DevOps ليست كلمة شاملة بما فيه الكفاية ؛ لا يزال هناك ما يكفي من كل أنواع العناصر المختلفة المثيرة للاهتمام. ونذهب إلى مختبراتنا السرية ونبدأ في إنتاج طفرات مثيرة للاهتمام: DevTestOps ، GitOps ، DevSecOps ، BizDevOps ، ProdOps.
المنطق هو الحديد ، أليس كذلك؟ نظام التسليم الخاص بنا غير فعال ، وأنظمتنا غير مستقرة والمستخدمون غير راضين ، وليس لدينا الوقت لنشر البرنامج في الوقت المحدد ، ولا نلائم الميزانية. كيف سنحل كل هذا؟ سنأتي بكلمة جديدة! سينتهي في العمليات ويتم حل المشكلة.
لذلك أنا أسمي هذا النهج - "مكتب خدمات المشاريع ، ويتم حل المشكلة."
كل هذا يتلاشى في الخلفية إذا ذكرنا أنفسنا لماذا توصلنا إلى كل هذا. لقد توصلنا إلى كل هذا DevOps لجعل تسليم البرامج وعملنا الخاص في هذه العملية بلا عائق ، غير مؤلم ، فعال ، والأهم من ذلك ، ممتعة.
نمت DevOps من الألم. ونحن تعبنا من المعاناة. ولكي يحدث هذا ، فإننا نعتمد على الممارسات الدائمة الخضرة: التعاون الفعال ، وممارسات التدفق ، والأهم من ذلك ، التفكير المنهجي ، لأنه بدون ذلك ، لا تعمل DevOps.
ما هو النظام؟
وإذا كنا نتحدث بالفعل عن التفكير المنهجي ، فلنذكر أنفسنا ما هو النظام.
إذا كنت متسللًا ثوريًا ، فهذا النظام بالنسبة لك هو الشر الشرير. هذه سحابة معلقة فوقك وتجعلك تفعل ما لا تريد القيام به.
من وجهة نظر التفكير النظامي ، النظام ككل يتكون من أجزاء. في هذا المعنى ، كل واحد منا هو نظام. المنظمات التي نعمل من أجلها هي أنظمة. وما نقوم ببنائه هو ما يطلق عليه - النظام.
كل هذا جزء من نظام اجتماعي كبير واحد. وفقط إذا فهمنا كيف يعمل هذا النظام الاجتماعي التكنولوجي معًا ، عندها فقط يمكننا حقًا تحسين شيء في هذا الشأن.
من وجهة نظر التفكير النظامي ، يتمتع النظام بالعديد من الخصائص المثيرة للاهتمام. أولاً ، يتكون من أجزاء ، مما يعني أن سلوكه يعتمد على سلوك الأجزاء. علاوة على ذلك ، كل أجزائه مترابطة أيضا. اتضح أنه كلما زاد عدد أجزاء النظام ، زاد صعوبة فهم سلوكه أو التنبؤ به.
من حيث السلوك ، هناك حقيقة أخرى مثيرة للاهتمام. يمكن للنظام القيام بشيء لا يمكن لأي من أجزائه الفردية القيام به.
كما قال الدكتور راسل أكوف (أحد مؤسسي التفكير النظامي) ، هذا سهل بما يكفي لإثباته بمساعدة تجربة فكرية. على سبيل المثال ، من في الجمهور يمكنه كتابة الكود؟ العديد من الأيدي ، وهذا أمر طبيعي ، لأن هذا هو أحد المتطلبات الأساسية لمهنتنا. يمكنك الكتابة ، ويمكن أن يديك كتابة التعليمات البرمجية بشكل منفصل عنك؟ هناك أناس يقولون: "يدي لا تكتب الكود ، ذهني يكتب الكود". هل يستطيع الدماغ كتابة الكود بشكل منفصل عنك؟ حسنا ، على الأرجح لا.
الدماغ عبارة عن آلة رائعة ، 10٪ منا لا يعرفون كيف تعمل هناك ، لكن لا يمكن أن يعمل بشكل منفصل عن النظام الذي يعمل به الجسم. وهذا سهل إثباته: افتح صندوق جمجمةك ، أخرج عقلك منه ، ضعه أمام الكمبيوتر ، واجعله يحاول كتابة شيء بسيط. "مرحبا ، العالم" في بيثون ، على سبيل المثال.
إذا كان النظام يستطيع فعل شيء لا يمكن لأي من أجزائه القيام به بشكل فردي ، فهذا يعني أن سلوكه لا يتحدد بسلوك أجزائه. ثم ما الذي تحدده؟ يتحدد بالتفاعل بين هذه الأجزاء. وبالتالي ، فكلما زاد عدد الأجزاء ، زاد صعوبة التفاعل ، زاد صعوبة فهم سلوك النظام والتنبؤ به. وهذا يجعل مثل هذا النظام فوضويًا ، لأن أي أصغر ، غير مرئي لتغيير العين في أي جزء من النظام يمكن أن يؤدي إلى نتائج غير متوقعة تمامًا.
تم اكتشاف هذه الحساسية للظروف الأولية لأول مرة والتحقيق فيها من قبل عالم الأرصاد الجوية إد لورنز. في وقت لاحق ، كان يطلق عليه "تأثير الفراشة" وأدى إلى تطوير مثل هذه الحركة من الفكر العلمي يسمى "نظرية الفوضى". أصبحت هذه النظرية واحدة من التحولات النموذجية الرئيسية في علوم القرن العشرين.
نظرية الفوضى
الناس الذين يدرسون الفوضى يسمون أنفسهم علماء الفلك.
في الواقع ، كان السبب وراء هذا التقرير هو أنه من خلال العمل مع الأنظمة الموزعة المعقدة والمنظمات الدولية الكبيرة ، أدركت في مرحلة ما أن هذا هو ما أشعر به. أنا عالم الفوضى. هذه بشكل عام طريقة مبتكرة للقول: "أنا لا أفهم ما يحدث هنا ولا أعرف ماذا أفعل به".
أعتقد أن العديد منكم يشعرون أيضًا بنفسك كثيرًا ، لذا فأنت أيضًا عالم فقه. أدعوكم إلى نقابة علماء الفلك. إن الأنظمة التي ندرسها ، نحن الزملاء الأعزاء في علماء الفلك ، تدعى "الأنظمة التكيفية المعقدة".
ما هي القدرة على التكيف؟ القدرة على التكيف تعني أن السلوك الفردي والجماعي للأجزاء في مثل هذا النظام التكيفي يتغير وينظم نفسه ، ويستجيب للأحداث أو سلاسل الأحداث الصغيرة في النظام. أي أن النظام يتكيف مع التغييرات من خلال التنظيم الذاتي. وتستند هذه القدرة على التنظيم الذاتي على التعاون التطوعي اللامركزي بالكامل لوكلاء الحكم الذاتي الحر.
خاصية أخرى مثيرة للاهتمام لهذه الأنظمة هي أنها قابلة للتطوير بحرية. أن نكون ، كمهندسين في علم الفلك ، بلا شك موضع اهتمام. لذا ، إذا قلنا أن سلوك النظام المعقد يتحدد بتفاعل أجزائه ، فما الذي يهمنا؟ التفاعل.
هناك استنتاجان أكثر إثارة للاهتمام.
أولاً ، نحن نفهم أنه لا يمكن تبسيط النظام المعقد من خلال تبسيط أجزائه. ثانياً ، الطريقة الوحيدة لتبسيط نظام معقد هي تبسيط التفاعلات بين أجزائه.
كيف نتفاعل؟ نحن جميعا جزء من نظام معلومات كبير يسمى المجتمع البشري. نتفاعل من خلال لغة مشتركة ، إذا كانت لدينا ، إذا وجدناها.
لكن اللغة نفسها نظام معقد للتكيف. وفقًا لذلك ، من أجل التفاعل بشكل أكثر كفاءة وبساطة ، نحتاج إلى إنشاء نوع من البروتوكولات. وهذا هو ، بعض تسلسل الرموز والإجراءات التي تجعل تبادل المعلومات بيننا أكثر بساطة وأكثر قابلية للتنبؤ بها وأكثر قابلية للفهم.
أريد أن أقول إن النزوع إلى التعقيد ، والتكيف ، واللامركزية ، والعشوائية يتم تتبعها في كل شيء. وفي تلك الأنظمة التي نبنيها ، وفي تلك الأنظمة التي نحن جزء منها.
ولكي لا تكون لا أساس لها من الصحة ، دعونا نلقي نظرة على كيفية تغير النظم التي ننشئها.
كنت تنتظر هذه الكلمة ، وأنا أفهم. نحن في مؤتمر DevOps ، اليوم ستظهر هذه الكلمة في مكان ما بمائة ألف مرة ، ثم سنحلم في الليل.
Microservices هي أول بنية برمجية ظهرت كرد فعل على ممارسات DevOps ، والتي تم تصميمها لجعل أنظمتنا أكثر مرونة وقابلية للتوسع وضمان التسليم المستمر. كيف تفعل هذا؟ عن طريق تقليل حجم الخدمات ، وتقليل حدود المشكلات التي تعالجها هذه الخدمات ، مما يقلل من وقت التسليم. وهذا يعني أننا نقوم بتقليل وتبسيط أجزاء النظام ، وزيادة عددهم ، وبالتالي ، يزداد تعقيد التفاعلات بين هذه الأجزاء باستمرار ، أي تنشأ مشاكل جديدة يتعين علينا حلها.
خدمات Microservices ليست هي النهاية ، خدمات microservices هي بشكل عام بالفعل بالأمس ، لأن Serverless قادم. جميع الخوادم محترقة ، لا خوادم ، لا توجد أنظمة تشغيل ، فقط كود قابل للتنفيذ نظيف. التكوين منفصل ، الدولة منفصلة ، كل شيء مدفوع بالحدث. الجمال ، النقاء ، الصمت ، لا أحداث ، لا شيء يحدث ، النظام الكامل.
أين هي الصعوبة؟ التعقيد ، بالطبع ، في التفاعلات. كم يمكن أن تفعل وظيفة واحدة من تلقاء نفسها؟ كيف تتفاعل مع وظائف أخرى؟ طوابير الرسائل وقواعد البيانات والموازنات. كيفية إعادة إنشاء حدث عند حدوث فشل؟ مجموعة من الأسئلة وبعض الإجابات.
Microservices و Serverless هي كل ما نطلق عليه محبو الكمبيوتر Cloud Native. كل شيء عن السحابة. لكن السحابة قابلة للتطوير بشكل أساسي أيضًا. لقد اعتدنا على التفكير فيه كنظام موزع. في الواقع ، أين تعيش خوادم مزود السحابة؟ في مراكز البيانات. وهذا هو ، لدينا نموذج معين ، وموزع للغاية وموزعة.
نفهم اليوم أن إنترنت الأشياء لم يعد مجرد كلمات كبيرة ، حتى وفقًا لتوقعات متحفظة ، فإن مليارات الأجهزة المتصلة بالإنترنت تنتظرنا في السنوات الخمس إلى العشر القادمة. هناك كمية هائلة من البيانات المفيدة وغير المجدية التي ستندمج في السحابة وتدفق من السحابة.
لن تقف السحابة ، لذلك نحن نتحدث بشكل متزايد حول ما يسمى "الحوسبة الطرفية". أو أود أيضًا التعريف الرائع للحوسبة الضبابية. ممزقة بتصوف الرومانسية والغموض.
الحوسبة الضبابية. النقطة المهمة هي أن الغيوم هي جلطات مركزية مثل الماء والبخار والجليد والحجارة. والضباب هو قطرات الماء المنتشرة حولنا في الجو.
في نموذج ضبابي ، يتم معظم العمل بواسطة هذه القطيرات بشكل مستقل بالكامل أو بالتعاون مع قطيرات أخرى. ولا يتحولون إلى السحابة إلا عندما يقومون بذلك.
وهذا هو ، مرة أخرى ، اللامركزية والاستقلال الذاتي ، وبالطبع ، فإن الكثير منكم يفهمون بالفعل ما يدور حوله كل هذا ، لأنه لا يمكنك التحدث عن اللامركزية وعدم ذكر سلسلة المفاتيح.
هناك أولئك الذين يعتقدون ، هؤلاء هم الذين استثمروا في العملة المشفرة. هناك أولئك الذين يؤمنون ، لكنهم خائفون ، مثلي ، على سبيل المثال. وهناك أولئك الذين لا يؤمنون. هنا يمكنك أن تتصل بشكل مختلف. هناك التكنولوجيا ، والأعمال التجارية الجديدة غير المفهومة ، وهناك مشاكل. مثل أي تقنية جديدة ، فإنه يثير أسئلة أكثر من الإجابات.
الضجيج حول blockchain أمر مفهوم. حتى لو وضعت جانباً الاندفاع الذهبي ، فإن التكنولوجيا نفسها تقدم وعودًا رائعة بمستقبل أكثر إشراقًا: المزيد من الحرية ، مزيد من الاستقلالية ، الثقة العالمية الموزعة. ما هناك لا تريد؟
وفقًا لذلك ، بدأ عدد متزايد من المهندسين حول العالم في تطوير التطبيقات اللامركزية. وهذه قوة لا يمكن تجاهلها بمجرد قول: "آه ، إن blockchain مجرد قاعدة بيانات موزعة بشكل سيئ التنفيذ". أو كيف يحب المتشككون أن يقولوا: "لا توجد استخدامات حقيقية لـ blockchain". إذا فكرت في الأمر ، فقبل 150 عامًا قالوا نفس الشيء عن الكهرباء. وحتى في بعض النواحي كانوا على صواب ، لأن ما تمكنت الكهرباء من تحقيقه اليوم في القرن التاسع عشر كان غير واقعي تمامًا بأي شكل من الأشكال.
بالمناسبة ، من يعرف نوع الشعار الموجود على الشاشة؟ هذا هو Hyperledger. هذا مشروع يتم تطويره تحت رعاية Linux Foundation ، وهو يتضمن مجموعة من تقنيات blockchain. هذه هي حقاً قوة مجتمعنا المفتوح المصدر.
الفوضى الهندسية
لذلك ، أصبح النظام الذي نطوره أكثر تعقيدًا ، وأكثر فوضوية ، وأكثر قدرة على التكيف. Netflix - رواد أنظمة الخدمات الميكروية. كانوا من أوائل من فهموا ذلك ، فقد طوروا مجموعة أدوات تسمى جيش Simian ، وأشهرها
Chaos Monkey . عرف ما أصبح يعرف باسم
"مبادئ هندسة الفوضى" .
بالمناسبة ، في عملية العمل على التقرير ، قمنا بترجمة هذا النص إلى اللغة الروسية ، لذلك انتقل إلى
الرابط ، والقراءة ، والتعليق ، والتوبيخ.
باختصار ، تشير مبادئ هندسة الفوضى إلى ما يلي. الأنظمة الموزعة المعقدة لا يمكن التنبؤ بها بطبيعتها ، ولديها أخطاء بطبيعتها. الأخطاء أمر لا مفر منه ، مما يعني أننا بحاجة إلى قبول هذه الأخطاء والعمل مع هذه الأنظمة بطريقة مختلفة تمامًا.
يجب أن نحاول نحن أنفسنا إدخال هذه الأخطاء في أنظمة الإنتاج الخاصة بنا من أجل اختبار أنظمتنا من أجل هذه القدرة على التكيف ، لهذه القدرة ذاتها على التنظيم الذاتي ، من أجل البقاء.
وهذا يغير كل شيء. ليس فقط كيفية تشغيل النظام في الإنتاج ، ولكن أيضًا كيفية تطويره ، وكيفية اختباره. لا توجد عملية تثبيت ، تجميد الكود ، على العكس ، هناك عملية مستمرة لزعزعة الاستقرار. نحن نحاول قتل النظام ونرى أنه يستمر في البقاء.
بروتوكولات تكامل النظام الموزعة
وفقا لذلك ، وهذا يتطلب أنظمتنا لتغيير أيضا بطريقة أو بأخرى. من أجل أن يصبحوا أكثر استقرارًا ، فهم بحاجة إلى بروتوكولات جديدة للتفاعل بين أجزائهم. بحيث يمكن لهذه الأجزاء التفاوض والتوصل إلى نوع من التنظيم الذاتي. وهناك كل أنواع الأدوات الجديدة ، البروتوكولات الجديدة ، والتي أسميها "بروتوكولات تفاعل الأنظمة الموزعة".
عن ماذا أتحدث؟ أولاً ، مشروع
Opentracing . يحاول البعض إنشاء بروتوكول مشترك للتتبع الموزع ، وهو أداة لا غنى عنها على الإطلاق لتصحيح أخطاء الأنظمة الموزعة المعقدة.
التالي هو
عامل السياسة المفتوحة . نقول إننا لا نستطيع التنبؤ بما سيحدث للنظام ، أي أننا بحاجة إلى زيادة قابليته للملاحظة. Opentracing هي مجموعة من الأدوات التي توفر إمكانية الملاحظة لأنظمتنا. لكننا نحتاج إلى الملاحظة من أجل تحديد ما إذا كان النظام يتصرف كما نتوقع منه أم لا. كيف يمكننا تحديد السلوك المتوقع؟ من خلال تحديد نوع ما من السياسة ، مجموعة من القواعد. يقوم مشروع Open Policy Agent بتعريف مجموعة القواعد هذه على نطاق واسع: من الوصول إلى تخصيص الموارد.
كما قلنا ، أنظمتنا مدفوعة بشكل متزايد الحدث. Serverless هو مثال رائع على أنظمة الأحداث. لكي نتمكن من نقل الأحداث بين الأنظمة وتتبعها ، نحتاج إلى لغة مشتركة ، وبعض البروتوكولات المشتركة لكيفية الحديث عن الأحداث ، وكيف ننقلها إلى بعضها البعض. هذا هو مشروع يسمى
Cloudevents .
إن التدفق المستمر للتغيرات التي تغسل أنظمتنا ، مما يؤدي إلى زعزعة استقرارها باستمرار ، هو دفق مستمر من القطع الأثرية للبرامج. حتى يتسنى لنا الحفاظ على هذا التدفق المستمر من التغييرات ، نحتاج إلى بروتوكول مشترك يمكننا من خلاله التحدث عن ماهية قطعة أثر البرنامج ، وكيف يتم التحقق منها ، والتحقق من صحتها. هذا هو مشروع يسمى
Grafeas . وهذا هو ، والبرمجيات الشائع قطعة أثرية بروتوكول.
وأخيرًا ، إذا أردنا أن تكون أنظمتنا مستقلة تمامًا ، وقابلة للتكيف ، وتنظيم ذاتي ، فيجب أن نمنحها الحق في التعرف على الذات. وهناك مشروع يسمى
spiffe يفعل ذلك تماما. هذا أيضًا مشروع ترعاه مؤسسة Cloud Native Computing Foundation.
كل هذه المشاريع صغيرة ، وكلها تحتاج إلى حبنا ، واختبارنا. هذا كل شيء مفتوح المصدر واختبارنا وتنفيذه. أنها تظهر لنا الطريقة التي تتحرك التكنولوجيا.
لكن DevOps لم تكن في المقام الأول تتعلق بالتكنولوجيا ، وكانت في المقام الأول تتعلق دائمًا بالتعاون بين الناس. وبالتالي ، إذا أردنا تغيير الأنظمة التي نطورها ، فعلينا تغيير أنفسنا. في الواقع ، نحن نتغير بالفعل ، ليس لدينا خيار معين.
يوجد
كتاب رائع للكاتبة البريطانية راشيل بوتسمان تكتب فيه عن تطور الثقة عبر تاريخ البشرية. تقول في البداية ، في المجتمعات البدائية ، كانت الثقة محلية ، أي أننا وثقنا فقط بمن نعرف شخصياً.
ثم كانت هناك فترة طويلة جدًا - وقت مظلم ، حيث كانت الثقة مركزية ، عندما بدأنا نثق في أشخاص لا نعرفهم على أساس أننا ننتمي إلى نفس المؤسسة العامة أو الحكومية.
وهنا هو ما نراه في عالمنا الحديث: الثقة أصبحت موزعة أكثر وأكثر لا مركزية ، وهي تقوم على حرية تدفق المعلومات ، وعلى توافر المعلومات.
إذا فكرت في الأمر ، فإن إمكانية الوصول هذه التي تجعل هذه الثقة ممكنة هي ما نقوم بتنفيذه.
هذا يعني أنه يجب تغيير الطريقة التي نعمل بها والطريقة التي نعمل بها ، لأن مؤسسات تكنولوجيا المعلومات الهرمية المركزية من النوع القديم تتوقف عن العمل. يبدأون بالموت.أساسيات منظمة DevOps
تعتبر منظمة DevOps المثالية للمستقبل نظامًا لامركزيًا متكيفًا يتكون من فرق مستقلة ، كل منها يتكون من أفراد مستقلين. تنتشر هذه الفرق في جميع أنحاء العالم ، وتتعاون بشكل فعال مع بعضها البعض باستخدام الاتصالات غير المتزامنة ، باستخدام بروتوكولات الاتصال شديدة الشفافية. جميلة جدا ، أليس كذلك؟ مستقبل جميل جدابالطبع ، كل هذا مستحيل بدون تغيير ثقافي. يجب أن يكون لدينا قيادة تحويلية ، مسؤولية شخصية ، دافع داخلي.
هذا هو أساس منظمات DevOps: شفافية المعلومات ، والاتصالات غير المتزامنة ، والقيادة التحويلية ، واللامركزية.الانطلاق
إن الأنظمة التي نحن جزء منها ، والأنظمة التي نبنيها ، أصبحت فوضوية على نحو متزايد ، ومن الصعب علينا ، نحن الناس ، التعامل مع هذه الفكرة ، والتخلي عن وهم السيطرة. نحن نحاول الاستمرار في السيطرة عليها ، وهذا غالبا ما يؤدي إلى الإرهاق. أقول هذا من خلال تجربتي الخاصة ، كما أنني تعرضت للإحراق ، وتم تعطيلي أيضًا في حالات فشل الإنتاج غير المتوقعة.
يحدث الإرهاق عندما نحاول التحكم في شيء لا يمكن التحكم فيه في جوهره. عندما نحترق ، يفقد كل شيء معناه ، لأننا نفقد الرغبة في القيام بشيء جديد ، نتخذ موقفًا دفاعيًا ونبدأ في الدفاع عما هو عليه.مهنة الهندسة ، كما أحب أن أذكر نفسي غالبًا ، هي مهنة إبداعية في المقام الأول. إذا فقدنا الرغبة في إنشاء شيء ما ، فسنتحول إلى رماد ، ونحول إلى رماد. يحترق الناس ، المنظمات بأكملها تحترق.في رأيي ، فإن قبول القوة الخلاقة للفوضى فقط ، وبناء التعاون على مبادئها هو ما يساعدنا على عدم فقد الخير في مهنتنا.ما أريده لك: أن تحب عملي ، وأن تحب ما نفعله. يتغذى هذا العالم على المعلومات ، ونحن نتشرف بإطعامها. لذلك دعونا ندرس الفوضى ، وسنكون علماء الفلك ، وسنحقق القيمة ، ونخلق شيئًا جديدًا جيدًا ، والمشاكل ، كما اكتشفنا بالفعل ، لا مفر منها ، وعندما تظهر ، سنقول ببساطة "Ops!" ، وسيتم حل المشكلة.ما بجانب الفوضى القرد؟في الواقع ، كل هذه الأدوات ، فهي صغيرة جدًا. تلك Netflix بنيت أدوات لأنفسهم. بناء أدوات لنفسك. اقرأ مبادئ هندسة الفوضى وامتثل لهذه المبادئ ، ولا تحاول البحث عن الأدوات الأخرى التي صممها شخص آخر بالفعل.حاول أن تفهم كيف تنكسر أنظمتك وابدأ في كسرها وشاهد كيف تصمد أمام التأثيرات. هذا هو أولا وقبل كل شيء. ويمكنك البحث عن الأدوات. هناك جميع أنواع المشاريع.لم أفهم تمامًا اللحظة التي قلت فيها إن النظام لا يمكن تبسيطه من خلال تبسيط مكوناته ، والتحول الفوري إلى خدمات microservices ، التي تبسط النظام من خلال تبسيط المكونات نفسها وتعقيد التفاعلات. وهذان أساسان يتعارضان مع بعضهما البعض.هذا صحيح ، الخدمات الميكروية هي موضوع مثير للجدل بشكل عام بشكل عام. في الواقع ، تبسيط الأجزاء يزيد من المرونة. ماذا تقدم الخدمات الصغيرة؟ إنها توفر لنا المرونة والسرعة ، لكنها بالتأكيد لا تمنحنا البساطة بأي شكل من الأشكال. أنها تزيد من التعقيد.هذا هو ، في فلسفة DevOps ، الخدمات المجهرية ليست نعمة؟أي خير لديه الجانب الخطأ. هناك فائدة: فهي تزيد من المرونة ، وتمنحنا القدرة على إجراء تغييرات بشكل أسرع ، ولكنها تزيد من التعقيد ، وبالتالي هشاشة النظام بأكمله.ومع ذلك ، ما هو التركيز أكثر على: تبسيط التفاعل أو تبسيط الأجزاء؟لا شك أن التركيز ينصب على تبسيط التفاعل ، لأنه إذا نظرنا إليه من وجهة نظر كيفية تعاملنا معك ، أولاً وقبل كل شيء ، نحتاج إلى الاهتمام بتبسيط التفاعلات ، وليس تبسيط عمل كل واحد منا على حدة. لأن تبسيط العمل يتحول إلى روبوتات. لكن في ماكدونالدز ، يعمل بشكل جيد عندما يتم وصفه لك: هنا تضع البرجر ، وهنا تصب عليه الصلصة. هذا في عملنا الإبداعي لا يعمل على الإطلاق.هل صحيح أن كل ما قلته يعيش في عالم بلا منافسة ، والفوضى هناك طيبة للغاية ، وليس هناك تناقضات داخل هذه الفوضى ، لا أحد يريد أن يأكل ، أو يقتل أحداً؟ كيف ينبغي للمنافسة و DevOps العيش؟حسنًا ، هذا يعتمد على نوع المنافسة التي نتحدث عنها. مكان العمل المنافسة أو المنافسة بين الشركات؟حول منافسة الخدمات الموجودة ، لأن الخدمات ليست شركات قليلة. نحن بصدد إنشاء نوع جديد من بيئة المعلومات ، وأي بيئة لا يمكن أن تعيش بدون منافسة. في كل مكان هناك منافسة.نفس Netflix ، نأخذها للحصول على نموذج يحتذى به. لماذا جاءوا بهذا؟ لأنهم بحاجة إلى أن تكون قادرة على المنافسة. هذه المرونة وسرعة الحركة ، وهذا هو بالضبط هذا الشرط التنافسي للغاية ، فإنه يقدم العشوائية في أنظمتنا. أي أن الفوضى ليست ما نفعله بوعي ، لأننا نريده ، إنه ما يحدث لأن العالم يتطلب ذلك. لدينا فقط للتكيف. والفوضى ، إنها مجرد نتيجة للمنافسة.هل هذا يعني الفوضى هي عدم وجود أهداف؟ أو تلك الأهداف التي لا نريد أن نرى؟ نحن في المنزل ولا نفهم أهداف الآخرين. المنافسة ، في الواقع ، يرجع ذلك إلى حقيقة أن لدينا أهداف واضحة ، ونحن نعرف أين سنأتي في كل لحظة في الوقت المناسب. في هذا ، من وجهة نظري ، جوهر DevOps.أيضا نظرة على السؤال. أعتقد أن لدينا جميعًا هدفًا واحدًا: البقاء على قيد الحياة والقيام بذلك بكلسرور. والهدف التنافسي لأي منظمة هو نفسه. البقاء في كثير من الأحيان في المنافسة ، لا يوجد شيء يجب القيام به.هذا العام ، سيعقد مؤتمر DevOpsDays موسكو في 7 ديسمبر في تكنوبوليس. حتى 11 نوفمبر ، نحن نقبل طلبات التقارير. مراسلتنا عبر البريد الإلكتروني إذا كنت تريد التحدث.
التسجيل للمشاركين مفتوح ، تكلفة تذكرة 7000 روبل. انضم الآن!