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

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

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


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

قبل شهر واحد

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

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

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



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

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

المشاكل

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

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

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

قبل يومين

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



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

اليوم الأول

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



لمدة يومين ، تم تحميل مستخدمي الصفحة بمعدل 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 أيام .

بعد ذلك نحن:

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

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

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

الأهداف طويلة الأجل:

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

عندما فعلت هذا ، لفت انتباهي شيئين:

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

لقد وجدت في الفريق ، على هذا النحو - كل من المطورين و Ops - لديهما ثلاث مشاكل كبيرة:

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

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

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

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

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

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

لم يحاول أحد من قبل أن يسأل لماذا يجب علينا ألا نفعل ذلك بشكل أفضل ، ولم يدرك أي شخص أنه لا ينبغي أن يكون كذلك.

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

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

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

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

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

استجابة لذلك ، قمت بتقديم الممارسات التالية:

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

اليوم الستون

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

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

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

نتائج المخزون:

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

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

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

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

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

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



وهذا هو ، كولد فيوجن يمر جيتي و nginx ويطلق الصفحات. والصور ، JS و CSS تمر عبر nginx منفصل مع التكوينات الخاصة بهم. هذه ممارسة قياسية إلى حد ما كتبت منذ بضع سنوات. , … 200 .



, , Jetty. — . , , , - 12%?

, — . , , .



— , . . - , .

استنتاج

. , , , . , , SEQUENCE . nextID , .

, . , , — .



. , :

• ;
• ;
• ;
• ;
• ;
• ;
• .

.

twitter , facebook medium .

legacy : , . c DevOpsConf , . youtube , , DevOps.