المطورون من المريخ، والإداريون من الزهرة

الصدف عشوائية، وفعلاً كانت في كوكب آخر..

أود أن أشارك ثلاث قصص نجاح وفشل حول كيفية عمل مطور الواجهة الخلفية ضمن فريق مع المسؤولين.

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

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

- مسؤولية عالية.
- خطر كسر الإنتاج.
— من الصعب أن تكون متخصصًا جيدًا في جميع المجالات.

غير مهتم، دعونا نمضي قدما

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

• متوسط ​​وقت النشر للإنتاج هو 4-5 ساعات
• الحد الأقصى لوقت النشر في الإنتاج 9 ساعات
• بالنسبة للمطور، يعد التطبيق قيد الإنتاج بمثابة صندوق أسود، تمامًا مثل خادم الإنتاج نفسه. كم هناك في المجموع؟
• انخفاض جودة الإصدارات والأخطاء المتكررة
• المطور لا يشارك في عملية الإصدار

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

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

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

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

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

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

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

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

القصة الثالثة
بدء. مشرف واحد، قسم التطوير الصغير. عند وصولي، كنت صفرًا كاملاً، لأن... ليس لدي أي وصول إلى أي مكان باستثناء البريد. نكتب إلى المسؤول ونطلب الوصول. بالإضافة إلى ذلك، هناك معلومات تفيد بأنه على علم بالموظف الجديد والحاجة إلى إصدار تسجيلات دخول/كلمات مرور. أنها توفر الوصول من المستودع وVPN. لماذا نمنح حق الوصول إلى wiki، وteamcity، وrundesk؟ أشياء عديمة الفائدة للشخص الذي تم استدعاؤه لكتابة الجزء الخلفي بأكمله. بمرور الوقت فقط يمكننا الوصول إلى بعض الأدوات. وبطبيعة الحال، قوبل الوصول بعدم الثقة. أحاول التعرف ببطء على كيفية عمل البنية التحتية للمشروع من خلال الدردشات والأسئلة التوجيهية. في الأساس أنا لا أتعرف على أي شيء. الإنتاج هو نفس الصندوق الأسود كما كان من قبل. ولكن أكثر من ذلك، حتى خوادم المرحلة المستخدمة للاختبار هي صندوق أسود. لا يمكننا فعل أي شيء سوى نشر فرع من Git هناك. لا يمكننا أيضًا تكوين تطبيقنا مثل ملفات .env. لا يتم منح الوصول لمثل هذه العمليات. يجب عليك التوسل لتغيير السطر في تكوين التطبيق الخاص بك على خادم الاختبار. (هناك نظرية مفادها أنه من الضروري أن يشعر المسؤولون بأهميتهم في المشروع؛ إذا لم يُطلب منهم تغيير الأسطر في التكوينات، فلن تكون هناك حاجة إليهم ببساطة). حسنًا، كما هو الحال دائمًا، أليس هذا مريحًا؟ سرعان ما يصبح هذا مملًا، بعد محادثة مباشرة مع المسؤول، اكتشفنا أن المطورين ولدوا لكتابة تعليمات برمجية سيئة، وهم بطبيعتهم أفراد غير أكفاء ومن الأفضل إبعادهم عن الإنتاج. ولكن هنا أيضًا من خوادم الاختبار، فقط في حالة. الصراع يتصاعد بسرعة. لا يوجد اتصال مع المشرف. ويتفاقم الوضع بسبب كونه وحيدا. وفيما يلي صورة نموذجية. يطلق. وظائف معينة لا تعمل. يستغرق الأمر منا وقتًا طويلاً لمعرفة ما يحدث، حيث يتم طرح أفكار مختلفة من المطورين في الدردشة، لكن المسؤول في مثل هذه الحالة عادةً ما يفترض أن المطورين هم المسؤولون. ثم يكتب في الدردشة، انتظر، لقد صححته. عندما يُطلب منا ترك قصة تحتوي على معلومات حول ماهية المشكلة، فإننا نتلقى أعذارًا سامة. مثل، لا تضع أنفك في مكان لا ينتمي إليه. يجب على المطورين كتابة التعليمات البرمجية. إن الموقف الذي تمر فيه العديد من حركات الجسم في المشروع من خلال شخص واحد ولا يتمكن سوى هو من تنفيذ العمليات التي يحتاجها الجميع هو أمر محزن للغاية. مثل هذا الشخص هو عنق الزجاجة الرهيب. إذا كانت أفكار Devops تسعى جاهدة لتقليل وقت طرحها في السوق، فإن هؤلاء الأشخاص هم أسوأ عدو لأفكار Devops. لسوء الحظ، يُغلق الستار هنا.

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

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