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

التصنيف: طبقة التنفيذ والسرعة

Toil | العمل الروتيني

التعريف

مصطلح أطلقه فريق Google SRE للدلالة على العمل الذي يتميز بخمس صفات: يدوي، متكرر، قابل للأتمتة، تكتيكي (لا استراتيجي)، ولا يُنتج قيمة دائمة. في سياق DX، الـ Toil هو كل ما يمنع المطور من كتابة كود ذي معنى.

• أمثلة شائعة: تحديث ملفات التهيئة يدوياً، نسخ بيانات بين بيئات، تشغيل سكربتات نشر يدوية
• يستهلك الـ Toil في المتوسط ٣٠-٤٠٪ من وقت المطور في المؤسسات التي لا تستثمر في الأتمتة
• القاعدة الذهبية من Google: إذا فعلتَ شيئاً يدوياً مرتين — أتمته في المرة الثالثة

مقياس DX

• يُقلّل: وقت الهندسة الفعلي والرضا ↓
• يزيد: الإحباط والاحتراق الوظيفي ↑
• هدف SRE: أقل من ٥٠٪ من وقت الفريق يذهب لـ Toil

سيناريو عملي

Low DX — Toil يومي (Laravel):

# لنشر تحديث بسيط:
ssh production
cd /var/www/app
git pull origin main
composer install --no-dev
php artisan migrate
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan queue:restart
sudo systemctl reload php-fpm
# ← 10 أوامر يدوية. نسيان واحد = كارثة.

High DX — Toil مُؤتمت (Laravel):

# .github/workflows/deploy.yml
# Push to main = نشر تلقائي
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: composer install --no-dev
      - run: php artisan migrate --force
      - run: php artisan optimize
      # ← أمر واحد: git push. الباقي يحدث تلقائياً.

High DX — Astro:

# Netlify / Vercel: صفر Toil
# git push → build → deploy → live
# لا أوامر، لا SSH، لا قلق

حالات واقعية

Google SRE — قاعدة الـ ٥٠٪

في كتاب Site Reliability Engineering (2016)، حددت Google قاعدة: لا يجب أن يتجاوز Toil ٥٠٪ من وقت المهندس. إذا تجاوز، يُخصص Sprint كامل للأتمتة. الفرق التي التزمت بالقاعدة حققت ٢× في سرعة توصيل الميزات مقارنة بالفرق التي تجاوزتها.

Lyft — قصة الأتمتة

Lyft اكتشفت أن المطورين يقضون ٨ ساعات أسبوعياً في إدارة بيئات الاختبار يدوياً. بنوا أداة داخلية تُنشئ بيئات اختبار بأمر واحد. النتيجة: استعادة ٦ ساعات من كل مطور أسبوعياً للعمل الهندسي.

Twitter/X — ميزانية Toil

خصصت Twitter ميزانية زمنية لـ Toil في كل Sprint: ١٠٪ فقط للمهام اليدوية. إذا تجاوزت، يُلغى أي عمل جديد ويُركز الفريق على الأتمتة حتى ينخفض الرقم.

التكلفة الحقيقية للـ Toil

مثال: مهمة نشر يدوية تستغرق ١٥ دقيقة

١٥ دقيقة × ٣ مرات/يوم × ٥ أيام × ٥٠ أسبوع = ١٨,٧٥٠ دقيقة/سنة
= ٣١٢ ساعة = ٨ أسابيع عمل كاملة لكل مطور

إذا كان لديك ١٠ مطورين = ٨٠ أسبوع عمل ضائع
= راتب مطور ونصف كامل يذهب للـ Toil

إحصائيات رئيسية

المقياس	القيمة	المصدر
وقت Toil في المؤسسات غير المؤتمتة	٣٠-٤٠٪	Google SRE Book
هدف SRE	< ٥٠٪	Google SRE Book
استعادة الوقت بعد الأتمتة	٦-٨ ساعات/أسبوع/مطور	Lyft Engineering
القاعدة الذهبية للأتمتة	هل فعلتها مرتين؟ أتمتها	Google SRE

اختبار: هل هذا Toil؟

السؤال	إذا “نعم”
هل هو يدوي؟	+١ نقطة
هل هو متكرر؟	+١ نقطة
هل يمكن أتمتته؟	+١ نقطة
هل ينمو مع حجم النظام؟	+١ نقطة
هل لا يُضيف قيمة دائمة؟	+١ نقطة
٣+ نقاط = Toil يجب أتمتته

مفاهيم مرتبطة

• الاحتكاك — Toil هو احتكاك متكرر
• الخدمة الذاتية للمطور — الحل المثالي لـ Toil
• المسار الذهبي — المسارات المُجهزة تُلغي Toil بالتصميم

نصيحة Monochrome

سجّل كل مهمة يدوية قام بها فريقك هذا الأسبوع. أي مهمة ظهرت مرتين — حوّلها إلى سكربت قبل يوم الجمعة.