تم إعداد ترجمة المقال خصيصًا لطلاب الدورة التدريبية "ممارسات وأدوات DevOps" .
مهمة الاتصال الداخلي هي جعل الأعمال التجارية عبر الإنترنت شخصية. لكن تخصيص منتج ما أمر غير ممكن عندما لا يعمل
كما ينبغي . تعد الكفاءة أمرًا مهمًا لنجاح أعمالنا ، وليس فقط لأن عملائنا يدفعون لنا ، ولكن أيضًا لأننا نستخدم
منتجاتنا بأنفسنا. إذا لم تنجح خدمتنا ، فنحن نشعر حرفيًا بألم عملائنا.
تعتمد مدة التشغيل على العديد من العوامل ، مثل هندسة البرمجيات وجودة العمل اليومي. ومع ذلك ، فغالبًا ما يتلخص كل ذلك في حقيقة أن الشخص الذي يكون دائمًا على اتصال يجيب على المكالمات من
PagerDuty . يمكن أن يكون هذا الدعم الفني أداة قوية موجهة نحو العملاء تجمع بين مساعدة المهندسين مع ما يتلقاه العملاء عند شراء منتجك. كما أنه يوفر فرصة رائعة للتعلم والنمو ، لأنه في النهاية ، يمكن أن تكون الإخفاقات والأخطاء مجالًا جيدًا لتطوير المهارات وفهم آليات العمل المعقدة.
البقاء "دائمًا على اتصال" خارج ساعات العمل يضر بحياتك.ولكن في الوقت نفسه ، يمكن أن يكون لحالة "دائمًا على اتصال" تأثير ضار على حياتك. يجب أن تكون مستعدًا للرد بسرعة وكفاءة على تنبيه بوجود شيء ما مكسور. حتى إذا لم يتم استدعاؤك من قِبل جهاز النداء في هذه اللحظة بالذات ، فإن حالة "دائمًا على اتصال" تغرس شعورًا بالقلق ، وأنا شخصياً أعرف ذلك من خلال تجربة شخصية. خاصة بسبب هذا ، فإن نوعية النوم تتدهور. قد تؤدي الإقامة المنتظمة في منطقة الوصول في أي وقت من اليوم إلى الإرهاق أو اللامبالاة أو بشكل عام إلى الرغبة في عدم رؤية الكمبيوتر مرة أخرى أبدًا.
سجل حالة الاتصال الداخلي في الاتصال الداخلي
في الأيام الأولى من الاتصال الداخلي ، كان مديرنا الفني كياران وحده فريقًا كاملًا من الدعم الفني على مدار الساعة ، سواء في المكتب أو في الخارج. عندما نشأ إنتركوم ، تم تشكيل فريق عمل لمساعدة سياران. بعد فترة وجيزة ، بدأت فرق التطوير الجديدة في إنشاء العديد من الميزات والخدمات الجديدة ، وقد تحملوا بالفعل جميع مسؤوليات الدعم الفني.
في أي لحظة كان هناك الكثير من الناس "على اتصال".في ذلك الوقت ، بدا أن هذا النهج يعتبر أمراً مفروغاً منه ، لأنه كان وسيلة سهلة لتوسيع نطاق فريق الدعم الفني في أي وقت ، حيث حقق قيمنا واستمتعت
بإحساسنا بالملكية . نتيجةً لذلك ، وبدون أي خطط ، وصلنا إلى أربعة أو خمسة فرق تتواصل بانتظام مع العملاء خلال ساعات بعدهم. لم يكن لدى بقية فرق التطوير العديد من اللحظات الصعبة التي يمكن أن تتسبب في حدوث خطأ ، لذلك نادراً ما تم استدعاءهم.
لقد أدركنا أننا في موقف نمتلك فيه آليات الدعم الفني ، والتي لا يمكن أن نفخر بها ، وعدد من المشكلات الخطيرة التي أردنا القضاء عليها ، مثل:
- الكثير من الناس كانوا على استعداد لقبول التحدي في أي وقت من الأوقات. لم تكن البنية التحتية الخاصة بنا كبيرة لدرجة أنها تتطلب ما لا يقل عن خمسة مهندسين للتطوير سيعملون دون عطلة نهاية أسبوع عادية.
- لم يتم تنسيق جودة أجهزة الإنذار وإجراءات الاتصال بين الفرق ؛ استخدمنا عمليات خاصة لمراجعة التنبيهات الجديدة والحالية حول المشاكل. كانت الإرشادات الواردة في سجل التشغيل (والتي يجب اتباعها عند تلقي إشعار حول مشكلة) ملفتة للنظر في الغالب.
- بناءً على الفريق الذي عمل فيه المهندسون ، كانت لديهم توقعات متضاربة. على سبيل المثال ، لم يتلق سوى فريق الدعم الفني الأول أي تعويض عن نوبات العمل وعطلات نهاية الأسبوع المنهارة.
- اتضح أن هناك مستوى عام من التسامح للمكالمات غير الضرورية في أوقات غير مناسبة.
- أخيرًا ، هذا النوع من العمل لا يناسب الجميع. أظهرت ظروف الحياة في بعض الأحيان أن نوبات الواجب تؤثر على الناس ليس في أفضل طريقة.
ابحث عن الحالة الصحيحة "دائمًا على اتصال"
قررنا إنشاء فريق افتراضي جديد يقوم بأعمال الدعم الفني لكل فريق عندما يكون لديه وقت عمل. سيتألف الفريق من متطوعين وليسوا من أي فريق في المنظمة. يتغير المهندسون في فريق افتراضي كل ستة أشهر تقريبًا ، ويمضون أسابيع "على اتصال". لحسن الحظ ، لم نواجه أي مشكلة في إيجاد عدد كاف من المتطوعين لتجميع فريق افتراضي.
ونتيجة لذلك ، تم تخفيض فريق الدعم الخاص بنا من 30 شخصًا إلى 6 أو 7 فقط.بعد ذلك وافق هذا الفريق وحدد شكل تنبيهات المشكلة والأوصاف التي يجب أن تبدو عليها في سجل التشغيل ، ووصف عملية إعادة توجيه التنبيهات إلى فريق دعم جديد. حددوا جميع التنبيهات في الكود باستخدام وحدة Terraform ، وبدأوا في استخدام حكم الخبراء لكل تغيير. قدمنا مستوى من التعويض عن التحول الأسبوعي ، والذي كان مناسبًا تمامًا لمن هم في الخدمة. أنشأنا أيضًا فريقًا متصاعدًا من المستوى الثاني ، يتألف من مديرين فقط. يجب أن يكون هذا الفريق نقطة التصعيد الوحيدة لمهندسي الدعم الفني.
كان لدينا عدة أشهر من العمل الشاق ، والتي بدأنا خلالها هذه العملية ، ونتيجة لذلك ، لم يعد هناك الآن 30 مهندسًا كما كان من قبل ، ولكن 6 أو 7 فقط ظلوا على اتصال. خلال ساعات العمل ، تتعامل الفرق بشكل مستقل مع مشاكل وظائفها أو خدماتها ، على هذه المرة عادة ما تمثل أكبر عدد من الأعطال ، ومع ذلك ، فإن بقية الوقت يشاركون في الدعم الفني.
ماذا تعلمنا
بعد أن أطلقنا فريق الدعم الفني الافتراضي لدينا ، توقعنا تدفق مهام جديدة ، مثل التحقيق في أسباب المشاكل أو تجمع عام لحل أي مشكلة واحدة تسببت في الفشل. ومع ذلك ، تحملت فرق التطوير لدينا المسؤولية الكاملة عن العوامل التي تسببت في الفشل ، وكان رد الفعل اللاحق عادةً إجراء فوري. لقد احتجنا أيضًا إلى تجنب الموقف الذي تتم فيه إعادة مهمة المشورة الفنية إلى الفريق الذي وصلت منه ، حتى لا تجبر المهندسين على الاتصال بعد ساعات.
انخفضت المكالمات خارج المكتب إلى أقل من 10 في الشهر.رسميا ، عملية التصعيد لدينا نادرا ما تستخدم. كان الرأي الأكثر شيوعًا هو أن المهندس ، الذي يعمل حاليًا عبر الإنترنت ، يساعد المهندس بشكل غير رسمي ، وخاصةً من رجالنا من المكتب في سان فرانسيسكو. تم إصلاح العديد من المشكلات أو تم تخفيض عددها من خلال العمل الجماعي وحلها أثناء الطيران.
انضم المهندسون في مكتبنا في سان فرانسيسكو إلى الفريق ككل وتجاوزوا الدعم الفني المعتاد. لقد واجهنا سؤالًا حول بعض التكاليف العامة ، ومع ذلك ، فقد تم توسيع عضوية فريق الدعم لتشمل العديد من المكاتب ، لأنه تبين أنها طريقة جيدة لبناء العلاقات وتعزيزها ومعرفة المزيد عن مجموعة التكنولوجيا التي نعمل معها جميعًا.
في فرقنا ، أصبح عمل مطوري Intercom أكثر ثباتًا ، ويمكننا أن نتحدث بثقة عن مزايا وظيفة مهندس نظام على موقع
Careers على الويب الخاص بنا ، موضحًا أنه ليست هناك حاجة لأن تكون دائمًا على اتصال إذا كنت لا ترغب في ذلك بنفسك.
بالإضافة إلى العمل الأساسي لتحقيق الاستقرار وتوسيع مستودعات البيانات الخاصة بنا ، فقد أدى الاهتمام المستمر بحل المشكلات إلى انخفاض عدد المكالمات خلال ساعات التوقف إلى أقل من 10 مكالمات في الشهر. نحن فخورون جدا بهذا الرقم.
نواصل العمل على صيانة فريق الدعم الفني لدينا وتحسينه ، ومع نمو الاتصال الداخلي ، قد يتعين علينا إعادة النظر في قراراتنا ، لأن ما يعمل اليوم لن يعمل بالضرورة في المرة القادمة التي يتضاعف فيها عدد موظفينا. ومع ذلك ، كانت هذه التجربة إيجابية للغاية لمنظمتنا ؛ فقد حسنت بشكل كبير من نوعية حياة مهندسين التطوير لدينا ، وجودة استجاباتنا للتحديات ، وقبل كل شيء ، تجربة عملائنا.