تحطيم بودكاست الحلقة 42 مع جيف سميث: ما هي DevOps؟

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

وتظهر الملاحظات

• جيف على تويتر
• كتاب جيف العمليات المضادة للأنماط ، حلول DevOps
• DevOps التي يمكن تحقيقها

تحديث اسبوعي

• سد الفجوة بين المصممين والمطورين بقلم ماثيو طالبي
• تفاعلات APIs مفيدة لبناء مكونات مرنة باستخدام TypeScript من تأليف Gaurav Khanna
• حلول CSS الذكية لتحديات واجهة المستخدم الشائعة بقلم Cosima Mielke
• نصائح وحيل لتقييم مصممي UX / UI بقلم ناتاليا سامبير
• حل مشكلات CLS في موقع التجارة الإلكترونية المدعوم من Next.js والذي كتبه Arijit Mondal

نسخة طبق الأصل

درو ماكليلان: إنه ممارس DevOps يركز على المستويات التي يمكن بلوغها من تطبيقات DevOps ، بغض النظر عن مكانك في رحلتك. إنه مدير عمليات الإنتاج في منصة الإعلانات الرقمية Centro ، بالإضافة إلى كونه متحدثًا عامًا ، يشارك معرفته في DevOps مع الجماهير في جميع أنحاء العالم. وهو مؤلف كتاب Operations Anti-Patterns و DevOps Solutions for Manning Publishing ، والذي يوضح كيفية تنفيذ تقنيات DevOps في نوع البيئات غير الكاملة التي يعمل فيها معظم المطورين. لذلك نحن نعلم أنه خبير في DevOps ، لكن هل تعلم جورج كلوني يعتبره أفضل صانع طائرات ورقية في جيل؟ أصدقائي المحطمون ، من فضلكم نرحب بجيف سميث. مرحبا جيف. كيف حالك؟

جيف سميث: أنا أحطم ، درو ، كيف حالك؟

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

جيف: إذا سألت 20 شخصًا عن DevOps ، فقد تحصل على 20 إجابة مختلفة. لذلك سوف أعطيك رأيي في الأمر ، حسنًا ، وأعلم أنه إذا كنت في مؤتمر وتذكر هذا ، فيمكنك الدخول في معركة بالأيدي مع شخص ما. لكن بالنسبة لي ، فإن DevOps يتعلق حقًا بهذه العلاقة بين ، ونركز على dev و ops ، ولكن في الحقيقة تلك العلاقة بين الفريق وكيف نبدأ في هيكلة عملنا والأهم من ذلك ، هيكلة أهدافنا وحوافزنا للتأكد من أنها تتماشى بحيث نعمل من أجل تحقيق هدف مشترك. والكثير من الأفكار والمفاهيم الأساسية من DevOps تأتي من العالم القديم حيث كان dev و ops دائمًا معاديين ، حيث كان هناك هذا الصراع المستمر. وعندما تفكر في الأمر ، يكون ذلك بسبب الطريقة التي يتم بها تحفيز هذين الفريقين. يتم تحفيز فريق واحد لدفع التغييرات. يتم تحفيز فريق آخر للحفاظ على الاستقرار ، مما يعني تغييرات أقل.

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

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

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

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

درو: كمطورين محترفين ، ما مدى أهمية أن يكون لدينا فهم جيد لماهية DevOps وماذا يعني التنفيذ؟

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

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

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

درو: عندما أفكر في الأشياء التي أسمعها عن DevOps ، أسمع مصطلحات مثل Kubernetes و Docker و Jenkins و CircleCI. لقد سمعت عن Kubernetes منذ سنوات. ما زلت لا أملك أي فكرة عما هو عليه ، ولكن مما تقوله ، يبدو أن DevOps لا يتعلق فقط ... نحن لا نتحدث فقط عن الأدوات هنا ، أليس كذلك؟ ولكن المزيد عن عمليات وطرق التواصل في سير العمل ، هل هذا صحيح؟

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

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

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

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

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

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

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

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

درو: ... مدى نجاح تنفيذ DevOps داخل المؤسسة.

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

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

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

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

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

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

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

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

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

جيف: بالضبط.

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

درو: عند اتباع نهج DevOps ، ما نوع الأشياء التي قد تتطلع إلى أتمتتها في مهام سير عملك؟ وما هي المكاسب التي تتوقعها من ذلك من خلال إكمال الأشياء يدويًا؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

درو: ثم لديك مشكلتان.

جيف: صحيح. حق. بالضبط. بالضبط. وأنت مثل ، "هل كتبته بشكل خاطئ؟ أم هذا؟ لا ، هذا الشيء معطل فعلا ". وبالتالي-

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

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

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

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

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

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

جيف: بالإضافة إلى أنه من الجيد أيضًا أن تكون قادرًا على مشاركة هذه المعلومات مع أشخاص آخرين لأنه بمجرد حصولك على البيانات ، يمكنك البدء في الحديث عن الأشياء في واقع مشترك ، صحيح ، لأن مشغول مصطلح عام ، ولكن 5200 طلب في الثانية شيء كثير أكثر واقعية يمكننا جميعًا التفكير فيه. وأعتقد أنه في كثير من الأحيان عندما نجري محادثات حول السعة أو أي شيء آخر ، فإننا نستخدم هذه المصطلحات المموجة يدويًا ، عندما نتمكن بدلاً من ذلك من النظر إلى لوحة القيادة وإعطاء قيم محددة للغاية والتأكد من أن كل شخص لديه حق الوصول إلى لوحات المعلومات هذه ، they're not hidden behind some ops wall that only we have access to for some unknown reason.

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. حق. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” حق.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. هل هذا تقييم عادل؟

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. حق. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. حق. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. حق. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. حق. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. حق؟ So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. حق. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. حق. So you could be doing any manner of testing in there that is extremely complicated. حق. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. حق. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. حق. Let me get Drew on the phone and see what's going on.” حق. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” حق. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. حق. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. You know what I mean? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

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

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

درو: يبدو أن كتابك واحد منهم ، ولكن هل هناك موارد أخرى يمكن للأشخاص الذين يتطلعون لبدء استخدام DevOps الرجوع إليها؟ هل هناك أماكن جيدة لتعلم هذه الأشياء؟

جيف: أجل. أعتقد أن DevOps For Dummies من تأليف إميلي فريمان مكان رائع للبدء. إنه حقًا يقوم بعمل رائع لفرز بعض المفاهيم والأفكار الأساسية ، وما نسعى إليه. لذلك سيكون هذا مكانًا جيدًا للبدء ، فقط للحصول على نوع من الأرض. أعتقد أن مشروع Phoenix هو مصدر رائع آخر لـ Gene Kim. وهذا شيء رائع ، هذا النوع من تمهيد الطريق لأنواع المشكلات التي لا يمكن أن تخلقها بيئة DevOps. وهو يقوم بعمل رائع نوعًا ما في إبراز هذه الأنماط والشخصيات التي تحدث والتي نراها في جميع أنواع المؤسسات مرارًا وتكرارًا. أعتقد أنه يقوم بعمل رائع نوعًا ما في تسليط الضوء على هؤلاء. وإذا قرأت هذا الكتاب ، أعتقد أنك ستنتهي بالصراخ في الصفحات قائلة ، "نعم ، نعم. هذه. هذه." لذلك ، هذا مكان رائع آخر.

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

درو: لقد تعلمت كل شيء عن DevOps. ما الذي كنت تتعلم عنه مؤخرًا يا جيف؟

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

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

درو: حسنًا ، القبعات كما قلت ، حتى بعد كل هذه السنوات ، على الرغم من أنني أفهم نوعًا ما مكان وجودها في المكدس ، ما زلت لا أملك أدنى فكرة عما يفعله Kubernetes.

جيف: أشعر بالتشابه في بعض الأحيان. يبدو الأمر وكأنه يفعل القليل من كل شيء ، أليس كذلك؟ إنه DNS للقرن الحادي والعشرين.

درو: إذا كنت ، المستمع ، ترغب في سماع المزيد من Jeff ، فيمكنك العثور عليه على Twitter ، حيث يكون في الظلام والحنان ، والعثور على كتابه وروابط للعروض التقديمية السابقة ومنشورات المدونة على موقعه ، attainabledevops.com. شكرا لانضمامك إلينا اليوم ، جيف. هل لديك اي كلمات فراق؟

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