حركة DevOps
Joe Schaeferأكثر من مجرد إعطاء المطورين الوصول الجذر!
أو لا حتى ذلك. الفكرة الكبرى وراء “حركة” ليس فقط إعطاء المطورين المزيد من الحبل;هذا’حول ضمان خطوط اتصال أفضل بين المطورين وفرق العمليات في المؤسسة. الكثير من هذا ليس جديدا، في الواقع’إعادة صياغة حركة kaizen ضمن سلاسل التوريد الصناعية التقليدية (السيارات) خلال القرن السابق. تعد لوحات كانبان مجرد أحدث إعادة تجميع للوحات معلومات عين الطيور (تضاعف كمديرين لمخزون سير العمل) تغطي الجهد اليومي الجماعي لشحن منتجات ذات جودة عالية تسعد العملاء وشركاء الأعمال على حد سواء.
تُعد إدارة القيود أمرًا أساسيًا للعملية. من خلال تحديد أي وجميع الاختناقات في النظام أولاً، يمكنك إعادة تركيز جهودك على تحسين هذه الموارد لتحقيق أقصى قدر من التأثير. التحسينات خارج تلك المناطق هي دائما تقريبا لا تستحق العناء — وستظل هذه الموارد تقيد سير العمل.
التطوير المستند إلى قناة الاتصال
يعد تشجيع التغييرات التزايدية مع عمليات الاختبار والترقية والإصدار التلقائية على إيقاع مجدول طريقة رائعة للحصول على الكرة المتدحرجة، لكن جزءًا كبيرًا من مراقبة الجودة في عمليات نشر SaaS/PaaS يتضمن اعتماد التطوير القائم على الجذع وفرعه من خلال مفاهيم التجريد. (يرجى زيارة الرابط لمناقشة شاملة للميزات والعيوب).
في جوهرها، الكون المتعدد على المدى الطويل خرئ فروع يخلق الخيال النفسي أن الجمع بين كل هذا العمل التنمية المحلية (والاختبار!) سوف يؤدي إلى كله الذي هو على الأقل كبيرة مثل مجموع أجزائه. والخبرة هي القاضي الأفضل، الذي يشير إلى أنه ينبغي تصميم مجموعات الميزات الجديدة الواسعة بشكل متزايد، في الموقع، على الكود المصدر الفرعي للإنتاج/الإصدار الحالي. في الأساس، تقوم بهندسة استراتيجيات التطوير الخاصة بك ضمن حدود فيزياء العالم البيولوجي، والتي تقول:
Surgery on a patient must result
in good outcomes (at all times) for
that patient, not just for siblings
or future generations.
مسارات التكامل المستمر/التسليم المستمر
التنمية القائمة على الجذع هي الأساس لجميع خطوط التحكم الآلي في التغيير التي نشأت خلال العقدين الماضيين.
القانون هو القانون (التطوير + البنية التحتية + التكوين).
قليلا من المنظور التاريخي أولا ؛ اللكم يتبع هذه الفقرات الأربع. الخيط المشترك هنا هو أن أباتشي كان دائما تقريبا قبل وقته.
العودة إلى ما قبلCFEngine في الأيام، احتفظت مؤسسة Apache Software Foundation بجميع ملفات تكوين تكنولوجيا المعلومات الخاصة بها ودعم البرامج النصية في CVS، وبالتالي Subversion. بالإضافة إلى ذلك، كل خدمة قمنا بتشغيلها لها علاقة “دفتر” لتوجيه المسؤولين مع أعمال الصيانة العملية.
كان سير العمل أقل من المثالي: بالإضافة إلى بناء شبكات منافذ FreeBSD التي تم تصحيحها محليًا في حزم (ثنائية) قابلة للنشر من البداية، كان على الموظفين ممارسة الانضباط *الذي يصعب فرضه عند نشر التغييرات على الإنتاج، من خلال الالتزام أولاً بالتحكم في الإصدار، وتسجيل الدخول إلى الخادم المستهدف، وتحديث تسجيل الخروج، وربما إعادة تشغيل الخدمة — كل هذا الكعب المتكرر الذي يتم تنفيذه باليد. في الواقع، معظم الوقت sysadmins اخترق مباشرة على الخادم المستهدف وملتزمة من ذلك الخادم’الخروج، مما يخاطر بالكثير من تعارضات الدمج على طول الطريق مع إعادة تحديث الشجرة (إما في ذلك الوقت، أو في مرحلة ما على الطريق من خلال الإجراءات المستقبلية التي ينفذها بعض الموظفين الآخرين). سير عمل أقل من الشفافية إلى حد ما، مع أمان إدارة كلمات المرور المشكوك فيه، لفريق عمليات تعاوني.
في الوقت الحاضر، يحتفظون بكل شيء في خرئ-شجرة مصدر الدمية المدعومة، وتوفير / نشر / تكوين مباشرة إلى السحابة باستخدام حزم Ubuntu العامة السابقة، والتي تعد نهجًا حديثًا إلى حد ما لعملها في مجال تكنولوجيا المعلومات، منذ جدولتها خرئ ستنشر عمليات السحب التي يقوم بها رئيس الدمى التحديثات في نهاية المطاف أثناء إيداع وكلاء الدمى. لكن الدمج المستمر/التسليم المستمر هو عمل قيد التقدم، حتى هذا اليوم.
من ناحية أخرى، كانت مبادرة شبيهة بـ CI في وقت مبكر ورائدة في ASF (للمشاريع الفعلية لبرمجيات Apache TLP) أباتشي غامبالذي كان من بنات أفكار زملاء بارعين مثل سام روبي والشركة. ما قام به القفز هو الخروج بشكل دوري، وبناء واختبار HEAD (بما في ذلك HEAD لجميع deps) من جذع كل قاعدة تعليمات برمجية في مستودع Subversion (ولكن يعود تاريخه إلى CVS) لكل مشروع يمكن أن يكتشف بنجاح كيفية البناء (الذي كان بشكل كبير يقتصر على مشاريع جافا في الأصل). وأرسلت التقارير تلقائيا إلى كل مجتمع إنمائي وأرشفت من أجل الأجيال القادمة. لا يزال نشاط أتمتة الزيت الثاقبة هذا مستمرًا (مع git) حتى يومنا هذا! أي مجتمع تطوير بحجم المؤسسة لا يقوم بتشغيل خادم Gump الخاص به هو 20y خلف أحدث التقنيات في ASF (IMO; don’لنبدأ في تبعيات وحدة البرنامج مفتوحة المصدر المثبتة بالإصدار في /trunk|master/ …).
هنا’s *النقطة في باختصار *: جميع مصادرك (التطوير والبنية التحتية والتكوين) تنتمي إلى التحكم في الإصدار (وليس بالضرورة مشاركة نفس المستودع) الذي يمكن مراجعته من قبل جميع موظفي التطوير، وهو جزء من مجموعتك الكاملة من خطوط أنابيب أتمتة الاختبار بين مراجعات التصحيح وعمليات نشر الإنتاج. هناك دراسة استقصائية عن حالة الفن، حيث يتم اختبار التغييرات / توفيرها / نشرها عند الطلب في إعدادات IaC/CaC، على صديقي وصديقي بول هامانت.’موقع ويب هنا. يرجى إلقاء نظرة!
المحاكاة الافتراضية مقابل الحاوية: a الحيوانات الأليفة مقابل الماشية الإعادة
أنظمة الحاويات مثل Docker هي تقنيات محاكاة افتراضية قابلة للتخصيص وقابلة لإعادة النشر تُستخدم عادةً لدعم إطار مجموعة تطبيقات بنية MicroService (MSA) مثل Kubernetes. يلتقطون حيث توقفت أنظمة المحاكاة الافتراضية، ويتداولون دعمًا غير محدود لأنظمة التشغيل المعزولة لكل جهاز ظاهري (VM) للأجهزة الافتراضية المستندة إلى نواة لينكس’s التي لديها تخصيص أكثر بكثير للبرمجة والتكامل مع مضيف لينكس الرئيسي الذي تعمل عليه. بالإضافة إلى ذلك، يمكن إعادة بنائها وتحميلها* إلى خدمة توزيع مركزية (مثل المصنع) لإعادة استخدامها على نطاق واسع عبر سلاسل تبعية متعددة وعمليات نشر الخادم القابلة للتنفيذ الأولية.
القياس الرأسي مقابل الأفقي
تسمح الحاويات القابلة لإعادة التكوين القابلة للتنزيل من خادم مركزي بتحقيق إمكانيات يصعب تحقيقها باستخدام تقنية المحاكاة الافتراضية الأساسية -‘t مقفل في أي خادم واحد’حدود الأجهزة لتوسيع نطاق خدماتك لتلبية الطلب. بمعنى آخر، يعد التوسع الأفقي عن طريق نشر نفس الحاوية عبر مجموعات المضيفين، عند الطلب، ميزة من الدرجة الأولى يمكن تحقيقها على الفور لأطر عمل MSA استنادًا إلى Docker. كما هو الحال في نشر عشرات الحاويات أكثر من أنوية وحدة المعالجة المركزية على مضيف same.
قياس جهود مكافحة الحرائق وكبحها ومكافحتها، سواء كانت حقيقية أو عملية
أحد الأشياء الرئيسية الأخرى التي يجب إدراكها هو التمييز بين العمل المخطط له والعمل غير المخطط له في أي من مقاييس تتبع الإنتاجية الخاصة بك، وكيفية تخصيص الموارد لتلك المهام. يصل العمل غير المخطط له إلى مكافحة الحرائق، وإذا تم إنفاق الكثير من الوقت (أكثر من حوالي 20٪) على هذه المهام، فإن العمل المخطط، وهو حاجة الأعمال الحقيقية للمؤسسة، يتراكم.
نادراً ما يمكن أن تتكيف الاختناقات في النظام مع العمل غير المخطط له، لذلك من المهم أن يكون لديك ما يكفي من الموارد الإضافية للتعامل مع الحمل المتزايد وما يترتب على ذلك من تراكم.
أحد دروس الاسترداد الرئيسة لكوفيد-19 في أوائل عام 2020، بصفته قدرة المستشفى من حيث تكنولوجيا المعلومات، هو أن هناك شيئًا مثل أن يكون قليلًا جدًا، على الأقل عندما يتعلق الأمر بتوظيف الموظفين (الأجهزة هي قصة أخرى). التخطيط للطوارئ ليوم ممطر، إما مع “زائدة” الموظفين أو مبادرات التدريب الشامل، جنبا إلى جنب مع التدريبات التحضيرية العادية، ليس فقط يبقي الطبيب بعيدا، ولكن هو في الواقع مهمة حاسمة.
التعامل مع البرنامج
على مستوى الإدارة، يعد منظور إدارة التغيير العالمي بين كل من التغييرات في التطوير والعمليات أمرًا حيويًا. يجب أن تكون كلتا المجموعتين على دراية ببعضهما البعض.’s التغييرات. من الناحية المثالية مع تفاصيل التخطيط المتاحة على طول الطريق. يمكن أن تحدث أشياء عظيمة عندما تكون الفرق مزيجًا صحيًا من موظفي التطوير والعمليات، في ثقافة عمل تعاوني قائمة على البيانات وشفافة.
إن فلسفة إشراك أصحاب المصلحة المتعددين في إنشاء منتج عمل ملموس، و التطور، لها آثار تتجاوز مجرد فرق dev و ops التي تشارك التحكم والمسؤولية عن جهد هندسة الخادم. يستمر تكرار هذا الدرس في جميع أنحاء عالم الشركات الحديث، حيث تتشكل المجالات الجديدة للتعبير البشري الإبداعي في قطاع الأعمال، وكذلك في إعادة ابتكار الطرق القديمة لممارسة الأعمال التجارية معًا.