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

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

يتحدث ليون باللغة الروسية بشكل ملون للغاية، لذلك إذا كان لديك 35-40 دقيقة، أوصي بمشاهدة الفيديو. نسخة نصية لتوفير الوقت أدناه.

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

قبل شهر واحد

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

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

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

بالنظر إلى الأمام قليلاً، سألاحظ أنني بدأت عملي خلال فترة أعلى حركة مرور سنوية، وهو أمر مثير للاهتمام لأسباب مختلفة.

كان النظام الأساسي، الذي يبدو أن عمره عامين فقط، يحتوي على مكدس غريب: ColdFusion وSQL Server من عام 2. ColdFusion، إذا كنت لا تعرف، وعلى الأرجح أنك لا تعرف، هو PHP مؤسسي ظهر في منتصف التسعينيات، ومنذ ذلك الحين لم أسمع به حتى. وكان هناك أيضًا: Ruby، وMySQL، وPostgreSQL، وJava، وGo، وPython. ولكن المتراصة الرئيسية تعمل على ColdFusion وSQL Server.

مشاكل

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

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

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

من يومين

قبل يومين من بدء عمل جديد، وصلت إلى المكتب، وملأت آخر الأوراق، والتقيت بالفريق، واكتشفت أن الفريق كان يعاني من مشكلة في ذلك الوقت. لقد قفز متوسط ​​وقت تحميل الصفحة إلى 4 ثوانٍ، أي مرتين.

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

يوم واحد

مر يومين وفي أول يوم عمل لي اكتشفت أن المشكلة لم تختف.

لمدة يومين، تم تحميل صفحات المستخدمين في المتوسط ​​خلال 4 ثوانٍ. أسأل إذا وجدوا ما هي المشكلة.

- نعم، فتحنا تذكرة.
- و؟
- حسنًا، لم يردوا علينا بعد.

ثم أدركت أن كل ما قيل لي عنه من قبل كان مجرد جزء صغير من جبل الجليد الذي كان عليّ محاربته.

هناك اقتباس جيد يناسب هذا جيدًا:

"في بعض الأحيان لتغيير التكنولوجيا عليك تغيير المنظمة."

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

لمدة ثلاثة أيام

لذلك، يستمر التحميل 4 ثوان، ومن 13 إلى 15 أكبر قمم.

وفي اليوم الثالث خلال هذه الفترة الزمنية، بدت سرعة التنزيل كما يلي:

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

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

ولكن يجب ألا ننسى أنه قبل أن تحصل على الإجابة الصحيحة، عليك أن تسأل السؤال الصحيح. سؤالي التالي كان: كم عدد خوادم الواجهة الأمامية لدينا؟ الجواب "لقد حيرني قليلاً" - كان لدينا 17 خادمًا أماميًا!

- أشعر بالحرج من السؤال، ولكن 150 مقسومة على 17 تعطي حوالي 8؟ هل تقول أن كل خادم يسمح بـ 8 طلبات في الثانية، وإذا كان هناك غدًا 160 طلبًا في الثانية، فسنحتاج إلى خادمين إضافيين؟

وبطبيعة الحال، لم نكن بحاجة إلى خوادم إضافية. كان الحل في الكود نفسه وعلى السطح:

var currentClass = classes.getCurrentClass();
return currentClass;

كانت هناك وظيفة getCurrentClass()لأن كل شيء على الموقع يعمل في سياق الفصل الدراسي - هذا صحيح. ولهذا كانت هناك وظيفة واحدة في كل صفحة أكثر من 200 طلب.

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

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

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

لكن حل هذه المشكلة الأولى أدى إلى خفض الرسم البياني إلى مستوى أقل بكثير.

وفي الوقت نفسه، كنا نقوم بتحسينات أخرى. كان هناك الكثير من الأشياء في الأفق والتي يمكن إصلاحها. على سبيل المثال، في نفس اليوم الثالث اكتشفت وجود ذاكرة تخزين مؤقت في النظام (في البداية اعتقدت أن جميع الطلبات تأتي مباشرة من قاعدة البيانات). عندما أفكر في ذاكرة التخزين المؤقت، أفكر في Redis أو Memcached القياسي. لكنني كنت الوحيد الذي اعتقد ذلك، لأن هذا النظام يستخدم MongoDB وSQL Server للتخزين المؤقت - وهو نفس النظام الذي تمت قراءة البيانات منه للتو.

اليوم العاشر

في الأسبوع الأول تعاملت مع المشكلات التي يجب حلها الآن. في مكان ما في الأسبوع الثاني، جئت إلى المنصة لأول مرة للتواصل مع الفريق، لمعرفة ما كان يحدث وكيف كانت العملية برمتها تسير.

تم اكتشاف شيء مثير للاهتمام مرة أخرى. يتكون الفريق من: 18 مطورًا؛ 8 مختبرين؛ 3 مدراء؛ 2 مهندسين معماريين. وقد شاركوا جميعًا في طقوس مشتركة، أي أن أكثر من 30 شخصًا كانوا يأتون إلى المنصة كل صباح ويخبرون بما فعلوه. ومن الواضح أن اللقاء لم يستغرق 5 أو 15 دقيقة. لم يستمع أحد لأي شخص لأن الجميع يعمل على أنظمة مختلفة. في هذا النموذج، كانت 2-3 تذاكر في الساعة لجلسة العناية الشخصية نتيجة جيدة بالفعل.

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

ونتيجة لذلك حصلنا على:

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

لقد ركزنا بشكل أساسي على الكفاءة والإنتاجية والجودة - هذه هي المشكلات التي حاولنا حلها من خلال تحويل الفريق.

اليوم الحادي عشر

في عملية تغيير هيكل الفريق، اكتشفت كيفية العد قصتناالنقاط. كانت 1 نقطة ذهنية تساوي يومًا واحدًا، وكانت كل تذكرة تحتوي على نقاط ذهنية لكل من التطوير وضمان الجودة، أي 2 نقطة ذهنية على الأقل.

كيف اكتشفت هذا؟

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

بعد هذا نحن:

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

اليوم العشرين

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

أهداف بعيدة المدى:

• منصة مدارة. مئات الطلبات في كل صفحة ليست جادة.
• اتجاهات يمكن التنبؤ بها. كانت هناك فترات ذروة دورية لحركة المرور لم تكن للوهلة الأولى مرتبطة بمقاييس أخرى - كنا بحاجة إلى فهم سبب حدوث ذلك وتعلم كيفية التنبؤ.
• توسيع المنصة. ينمو العمل باستمرار، ويأتي المزيد والمزيد من المستخدمين، وتتزايد حركة المرور.

في الماضي كان يقال كثيراً: "دعونا نعيد كتابة كل شيء في [اللغة/الإطار]، كل شيء سوف يعمل بشكل أفضل!"

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

• يعكس مهمة وأهداف المشروع؛
• يعطي الأولوية للأهداف الرئيسية؛
• يحتوي على جدول زمني لتحقيقها.

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

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

على سبيل المثال، أحد مؤشرات الأداء الرئيسية التنظيمية هو زيادة حصة السوق من خلال المنتجات الجديدة.

كيف يمكنك دعم هدف الحصول على المزيد من المنتجات الجديدة؟

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

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

وبالتالي، فإن كل قرار، بما في ذلك إعادة كتابة التعليمات البرمجية، يجب أن يدعم الأهداف المحددة التي حددتها الشركة لنا (النمو التنظيمي، والميزات الجديدة، والتوظيف).

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

اليوم الثلاثون

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

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

فارق بسيط آخر مثير للاهتمام هو أن العقد المبرم مع أحد أكبر العملاء ينص على أن جميع إصدارات البرامج التي تدعمها المنصة يجب أن تكون n-1، أي ليس الإصدار الأحدث، ولكن الإصدار قبل الأخير.

من الواضح إلى أي مدى كنا بعيدين عن n-1 إذا كان النظام الأساسي يعتمد على ColdFusion وSQL Server 2008، والذي لم يعد مدعومًا على الإطلاق في يوليو.

اليوم الخامس والأربعون

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

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

عندما فعلت ذلك لفت انتباهي أمران:

• نسبة عالية من التذاكر التي تم إرجاعها من ضمان الجودة إلى المطورين؛
• استغرقت مراجعات طلبات السحب وقتًا طويلاً.

كانت المشكلة أن هذه الاستنتاجات كانت مثل: يبدو أن الأمر يستغرق الكثير من الوقت، لكننا لسنا متأكدين من المدة.

"لا يمكنك تحسين ما لا يمكنك قياسه."

كيفية تبرير مدى خطورة المشكلة؟ هل يضيع أيامًا أم ساعات؟

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

أضفنا أيضًا "قيد المراجعة" لمعرفة عدد التذاكر في المتوسط ​​للمراجعة، ومن هنا يمكنك البدء بالرقص. كان لدينا مقاييس النظام، والآن أضفنا مقاييس جديدة وبدأنا في القياس:

• كفاءة العملية: الأداء والمخطط/تسليمها.
• جودة العملية: عدد العيوب والعيوب من ضمان الجودة.

إنه يساعد حقًا على فهم ما يجري بشكل جيد وما لا يسير على ما يرام.

اليوم الخمسون

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

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

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

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

ليس لدي إجابة جيدة لسؤال ما هو التوازن الصحيح، وكيفية الحفاظ عليه، وكم عدد الأشخاص الذين يجب الاحتفاظ بهم، وما هو مقدار الدفع الذي يجب دفعه. هذه عملية فردية بحتة.

اليوم الواحد والخمسون

بدأت أنظر عن كثب إلى الفريق لأفهم من لدي، وتذكرت مرة أخرى:

"معظم المشاكل هي مشاكل الناس."

لقد وجدت أن الفريق في حد ذاته - كل من Dev وOps - يواجه ثلاث مشاكل كبيرة:

• الرضا عن الوضع الحالي.
• انعدام المسؤولية - لأنه لم يسبق لأحد أن جلب نتائج عمل فناني الأداء للتأثير على العمل.
• الخوف من التغيير.

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

لكن لا يمكنك أن تتحسن دون تغيير أي شيء.

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

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

• تحميل 12 ثانية؛
• 5-10 دقائق توقف لكل إصدار؛
• يستغرق استكشاف المشكلات الحرجة وإصلاحها أيامًا وأسابيع؛
• نقص الموظفين المناوبين على مدار 24 ساعة طوال أيام الأسبوع / عند الطلب.

لم يحاول أحد قط أن يتساءل لماذا لا نقوم بالأمر بشكل أفضل، ولم يدرك أحد قط أن الأمر لا يجب أن يكون بهذه الطريقة.

على سبيل المكافأة، كانت هناك مشكلة أخرى: نقص الخبرة. رحل الكبار، ونشأ بقية الفريق الشاب في ظل النظام السابق وتسمم به.

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

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

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

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

ردًا على ذلك، قمت بتقديم الممارسات التالية:

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

اليوم الستين

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

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

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

نتائج الجرد:

• لقد تركنا نفس مركز البيانات.
• لقد أنهينا العقد مع 3 خدمات سجل. لأنه كان لدينا 5 منها - كل مطور بدأ اللعب بشيء ما أخذ واحدًا جديدًا.
• تم إغلاق 7 أنظمة AWS. ومرة أخرى، لم يوقف أحد المشاريع الميتة، بل استمرت جميعها في العمل.
• خفض تكاليف البرمجيات بنسبة 6 مرات.

اليوم الخامس والسبعون

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

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

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

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

وهذا يعني أن ColdFusion يمر عبر Jetty وnginx ويقوم بتشغيل الصفحات. والصور، JS وCSS تمر عبر nginx منفصل بتكويناتها الخاصة. هذه ممارسة قياسية إلى حد ما أتحدث عنها писал قبل بضع سنوات. ونتيجة لذلك، يتم تحميل الصور بشكل أسرع بكثير، وزاد متوسط ​​سرعة التحميل بمقدار 200 مللي ثانية.

حدث هذا لأن الرسم البياني تم إنشاؤه بناءً على البيانات التي تأتي مع Jetty. وهذا هو، المحتوى السريع غير مدرج في الحساب - قفز متوسط ​​\u12b\uXNUMXbالقيمة. كان هذا واضحا لنا، ضحكنا، لكن كيف يمكننا أن نشرح لمجلس الإدارة لماذا فعلنا شيئا وساءت الأمور بنسبة XNUMX%؟

اليوم الخامس والثمانون

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

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

اختتام

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

كان هناك مليون شيء مشابه يمكننا التحدث عنه لفترة طويلة. لكن الشيء الأكثر أهمية الذي لا يزال يتعين قوله هو الثقافة.

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

• لا يخافون من الفشل.
• تعلم من الأخطاء؛
• التعاون مع فرق أخرى؛
• أخذ زمام المبادرة؛
• تحمل المسؤولية؛
• نرحب بالنتيجة كهدف؛
• الاحتفال بالنجاح.

مع هذا سيأتي كل شيء آخر.

ليون فاير على تويتر, فيس بوك و متوسط.

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

المصدر: www.habr.com