تكون السيرة الذاتية لدور DevOps أو هندسة المنصات أكثر إقناعا عندما تبرز الموثوقية، ومسؤولية المناوبة الطارئة، وعمليات نقل البنية التحتية، والأدوات التي تعتمد عليها فرق أخرى، بدلا من النقاط التي تركز على الميزات والتي تعتمدها سيرة مهندس برمجيات عامة غالبا. تشترك السيرتان في معظم الآليات نفسها: خبرة بترتيب زمني عكسي، ملخص قصير، قسم مهارات، ونقاط تصف النتائج لا المهام. ما يتغير هو أي النتائج تُعد فعلا مثيرة للإعجاب في هذا الدور، لأن المستفيدين من عمل البنية التحتية هم غالبا مهندسون آخرون لا المستخدمون النهائيون، وغالبا ما يبقى العمل نفسه غير مرئي عندما يسير على ما يرام.
لماذا يتغير التركيز
عادة ما تكون لدى الميزة التي يبنيها مهندس برمجيات صورة واضحة لما قبل وما بعد: شاشة لم تكن موجودة، أو تدفق كان يستغرق خمس خطوات وأصبح يستغرق خطوتين. نادرا ما يحقق عمل البنية التحتية والمنصات هذا الأثر المرئي نفسه، لأن أفضل نتيجة ممكنة غالبا هي ألا يتغير شيء من وجهة نظر المستخدم، فعملية نشر كانت تُوقظ أحدهم الساعة الثانية فجرا لم تعد تفعل ذلك، وخدمة كانت تنهار تحت الضغط لم تعد تنهار. يجب على السيرة الذاتية لهذا النوع من الأدوار أن تجعل تلك الموثوقية غير المرئية مفهومة لقارئ لم يعمل في البنية التحتية من قبل، بذكر ما اعتمد على العمل وما كان سيتعطل من دونه.
وصف الموثوقية ووقت التشغيل بصدق
يحمل عمل الموثوقية الفخ نفسه المذكور في قياس الأثر الهندسي في السيرة الذاتية من دون اختلاق أرقام: رقم مغر لكن غير قابل للتحقق مثل "تحسين وقت التشغيل بنسبة 40٪" بينما لم يُرصد قط رقم كهذا فعليا. وحيثما وُجد مقياس حقيقي يمكن الرجوع إليه حاليا من لوحة بيانات أو تقرير حادثة، فمكانه في السيرة الذاتية كما هو. وحيثما لم يوجد، تحمل لغة النطاق والحالة قبل وبعد الوزن نفسه من دون المخاطرة، كم عدد الخدمات التي كانت وراء التغيير، وما الذي كان يتعطل وتوقف عن التعطل.
المناوبة الطارئة والاستجابة للحوادث كمحتوى في السيرة الذاتية
تستحق المسؤولية عن المناوبة الطارئة ذكرا مباشرا بدلا من طيها في سطر غامض مثل "دعم أنظمة الإنتاج"، لأنها تدل على مستوى من المسؤولية التشغيلية لا يحمله دور يركز على الميزات فقط. ما يُقرأ جيدا هو شكل تلك المسؤولية: أي نظام أو أنظمة كنت مسؤولا عن مناوبتها، وكيف كان دوران المناوبة تقريبا، وأمر ملموس واحد تغير بسبب حادثة تعاملت معها، مثل دليل إجراءات لم يكن موجودا من قبل وأصبح موجودا بعدها.
عمليات النقل وتغييرات البنية التحتية الجديرة بالذكر
تستحق عملية نقل أو تغيير منصة أو تبديل أداة نقطتها الخاصة عندما تكون من نوع المشاريع التي اضطر مهندسون آخرون للتكيف معها، لا تغييرا داخليا بحتا لم يلاحظه أحد خارج الفريق. ذكر ما تغير ولماذا يقدم عادة معلومات أكثر من مجرد ذكر اسم التقنية المستهدفة وحده.
الأدوات التي تعتمد عليها فرق أخرى
تستحق الأدوات الداخلية المعاملة نفسها التي تحصل عليها ميزة موجهة للعملاء: ماذا تفعل، ومن استخدمها، وماذا استبدلت. يتناول مقال عرض المشاريع الجانبية في سيرة مهندس البرمجيات البنية الأساسية نفسها للعمل المبني خارج وظيفة رسمية، وهي تنطبق بالقدر نفسه على أداة داخلية بُنيت ضمن وظيفة رسمية.
مثال توضيحي: إعادة صياغة نقطة حول ملكية البنية التحتية
قبل، غامضة وموجهة نحو الميزات: "عملت على البنية التحتية والنشر لفريق الواجهة الخلفية." بعد، أُعيدت صياغتها حول الملكية والنطاق وحالة قبل وبعد: "تولّيت مسؤولية خط أنابيب النشر لإحدى عشرة خدمة تابعة لفريق الواجهة الخلفية؛ كان خط الأنابيب يتطلب سابقا خطوة موافقة يدوية لكل خدمة قبل النشر، وبعد إعادة الكتابة، أصبحت مجموعة اختبارات ناجحة كافية للنشر التلقائي، ما خفض عدد المهندسين اللازم توفرهم وقت الإصدار من ثلاثة إلى واحد."
تجميع قائمة طويلة من الأدوات والمنصات
يمتد قسم المهارات لمهندس المنصات غالبا أطول من قسم مطور عادي، إذ يشمل مزودي الحوسبة السحابية وأدوات التنسيق وأنظمة المراقبة واللغات في آن واحد، وهو تماما النوع من القوائم الطويلة والمختلطة التي تستفيد من التجميع حسب الفئات بدلا من سطر واحد غير مرتب.
أنشئ سيرتك الذاتية
بُني قالب Developer من CVBuilderKit حول مدخلات موجهة بالمشاريع والملكية، ما يناسب عمل البنية التحتية والمنصات بقدر ما يناسب كود التطبيقات. ابدأ منه، أو من مستند فارغ، في أداة الإنشاء وأعد صياغة نقاطك حول الموثوقية والمناوبة الطارئة وعمليات النقل حول ما اعتمد فعلا على العمل قبل اللجوء إلى رقم لا يمكنك حاليا إثباته.