المراقبة والسجلات والتنبيهات
💡 دليل التعلم: لا يتطلب هذا الفصل أي أساس برمجي، حيث يأخذك عبر عروض توضيحية تفاعلية لفهم نظام المعرفة الكامل للعمليات. من المراقبة والتنبيهات إلى استكشاف الأخطاء وإصلاحها، ومن تخطيط السعة إلى الأتمتة التشغيلية، ستتقن بشكل شامل مهارات تشغيل الأنظمة الإنتاجية.
0. المقدمة: إطلاق النظام ليس سوى البداية
يعتقد العديد من المبتدئين: "بمجرد نشر الكود، تكتمل المهمة."
هذا خطأ كبير!
إطلاق النظام هو فقط نقطة البداية لأعمال التشغيل. تماماً مثل شراء سيارة جديدة، فالصيانة اللاحقة والإصلاح والتزود بالوقود هي الحالة الطبيعية.
للعمليات ثلاثة أهداف:
- الاستقرار (Stability): عدم تعطل النظام، وبقاء الخدمة متاحة دائماً
- الأداء (Performance): استجابة سريعة، وتجربة مستخدم جيدة
- الأمان (Security): عدم تسرب البيانات، ومنع الهجمات
1. نظام المراقبة (Monitoring)
المراقبة هي "عيون" العمليات. النظام بدون مراقبة يشبه القيادة بشكل أعمى، حيث لا تعرف حتى بوجود مشكلة.
1.1 المستويات الثلاثة للمراقبة
实时监控面板 (Monitoring Dashboard)
运维的"眼睛" - 让系统状态一目了然
CPU 使用率45%
正常
内存使用率62%
正常
磁盘使用率78%
警告
网络带宽34%
正常
磁盘 I/O55%
正常
负载均衡42%
正常
正常 (Normal)
警告 (Warning)
严重 (Critical)
مراقبة البنية التحتية: التركيز على موارد أجهزة الخادم
- استخدام CPU
- استخدام الذاكرة
- مساحة القرص و I/O
- عرض النطاق الترددي للشبكة
مراقبة التطبيقات: التركيز على حالة تشغيل البرمجيات
- QPS (عدد الطلبات في الثانية)
- زمن الاستجابة (التأخير)
- معدل الأخطاء
- حالة استدعاء الخدمات التابعة
مراقبة الأعمال: التركيز على صحة الأعمال
- DAU/MAU (المستخدمون النشطون يومياً/شهرياً)
- حجم الطلبات
- معدل نجاح الدفع
- معدل الاحتفاظ بالمستخدمين
1.2 مجموعة أدوات المراقبة
| الأداة | الاستخدام | الخصائص |
|---|---|---|
| Prometheus | جمع وتخزين المؤشرات | قاعدة بيانات سلاسل زمنية، مناسبة لبيانات المراقبة |
| Grafana | لوحات العرض المرئية | رسوم بيانية ولوحات معلومات قوية |
| Zabbix | مراقبة شاملة | أداة قديمة، وظائف شاملة |
| Datadog | منصة مراقبة SaaS | حل شامل، مدفوع |
نقطة أساسية: يجب أن تكون المراقبة متعددة المستويات، تغطي كل شيء من البنية التحتية إلى الأعمال، لتجنب "النقاط العمياء".
2. نظام التنبيهات (Alerting)
بعد أن تكتشف المراقبة مشكلة، يجب إخطار فريق العمليات في الوقت المناسب، وهذا هو التنبيه.
2.1 سير عملية التنبيه
告警流程 (Alerting Flow)
从发现异常到通知运维的自动化流程
1
监控采集
Prometheus 每隔 15s 采集一次指标
→
2
规则评估
Alertmanager 评估是否满足告警条件
→
3
告警分组
相似告警合并，避免轰炸
→
4
静默判断
检查是否在静默时间（如维护窗口）
→
5
路由分发
根据标签分发到不同接收器
→
6
发送通知
通过钉钉/邮件/短信通知值班人员
告警级别说明
P0最高优先级，立即处理（如核心服务宕机）
P1高优先级，30分钟内处理（如部分功能异常）
P2中优先级，当天处理（如性能下降）
P3低优先级，本周处理（如资源使用率偏高）
2.2 تصميم مستويات التنبيه
التصنيف المنطقي للتنبيهات يتجنب "إرهاق التنبيهات":
| المستوى | وقت الاستجابة | السيناريوهات النموذجية | قنوات الإشعار |
|---|---|---|---|
| P0 | فوراً (خلال 5 دقائق) | تعطل الخدمات الأساسية، فشل الدفع | مكالمة + SMS + DingTalk |
| P1 | خلال 30 دقيقة | أعطال جزئية في الوظائف، تدهور حاد في الأداء | SMS + DingTalk + بريد إلكتروني |
| P2 | معالجة في نفس اليوم | ارتفاع معدل استخدام الموارد، أخطاء متقطعة | DingTalk + بريد إلكتروني |
| P3 | معالجة خلال الأسبوع | مشاكل غير أساسية، اقتراحات تحسين | بريد إلكتروني |
2.3 تقارب التنبيهات وتقليل الضوضاء
نقطة الألم: مشكلة صغيرة قد تؤدي إلى مئات أو آلاف التنبيهات، مما يجعل الموظف المناوب مخدراً.
الحلول:
- تجميع التنبيهات: دمج التنبيهات المتشابهة (مثل دمج مشاكل متعددة من نفس الخادم في تنبيه واحد)
- كبت التنبيهات: إذا تم تشغيل تنبيه المشكلة الأصلية، لا تتكرر تنبيهات المشاكل الفرعية
- قواعد الإسكات: إيقاف التنبيهات تلقائياً أثناء الصيانة
- تحديد التردد: عدم تكرار نفس التنبيه خلال فترة قصيرة
نقطة أساسية: يجب أن تكون التنبيهات "قليلة ودقيقة"، كل تنبيه يستحق المعالجة.
3. إدارة السجلات (Logging)
السجلات هي "الصندوق الأسود" لاستكشاف المشكلات.
3.1 مستويات السجلات
javascript
console.debug('معلومات تفصيلية للتصحيح') // للاستخدام أثناء التطوير
console.info('معلومات عامة') // سجل سير العمليات العادي
console.warn('معلومات تحذيرية') // مشاكل محتملة
console.error('معلومات خطأ') // أخطاء تستدعي الانتباه3.2 السجلات المنظمة
السجلات التقليدية (غير جيدة):
2024-01-15 10:23:45 ERROR User john failed to login, attempts=3, ip=192.168.1.100السجلات المنظمة (موصى بها):
json
{
"timestamp": "2024-01-15T10:23:45Z",
"level": "ERROR",
"message": "User login failed",
"user": "john",
"attempts": 3,
"ip": "192.168.1.100",
"service": "auth-service"
}3.3 مجموعة ELK للسجلات
ELK = Elasticsearch + Logstash + Kibana
- Logstash: جمع وتصفية السجلات
- Elasticsearch: تخزين السجلات والبحث فيها
- Kibana: استعلام وعرض مرئي للسجلات
أفضل الممارسات:
- ✅ لا تسجل المعلومات الحساسة (كلمات المرور، tokens) في السجلات
- ✅ يجب تسجيل العمليات الأساسية (تسجيل الدخول، الدفع، تغيير الصلاحيات)
- ✅ يجب أن تحتوي السجلات على السياق (معرف المستخدم، معرف الطلب، الطابع الزمني)
- ✅ تنظيف السجلات منتهية الصلاحية بانتظام لتجنب امتلاء القرص
4. تتبع الروابط (Tracing)
في هندسة الخدمات المصغرة، قد يمر طلب واحد عبر عشرات الخدمات، كيف نتتبع مساره الكامل؟
Trace ID و Span ID
- Trace ID: المعرف الفريد لسلسلة الطلب بأكملها (مثل رقم تتبع الشحنة)
- Span ID: معرف استدعاء خدمة واحدة (مثل كل محطة عبور)
4.1 عرض تتبع موزع
分布式链路追踪 (Distributed Tracing)
一个请求在微服务间流转的完整路径
Trace ID：a1b2c3d4-e5f6-7890-abcd-ef1234567890
总耗时：450ms
调用服务数：6
0ms
45ms
90ms
135ms
180ms
225ms
270ms
315ms
360ms
405ms
450ms
API Gateway
⚠
User Service
✓
Product Service
✓
Inventory Service
✓
Payment Service
✓
Order Service
✓
正常 (≤200ms)
慢调用 (>200ms)
错误
💡 观察要点
- 点击"性能瓶颈"查看数据库查询慢导致的延迟
- 点击"错误追踪"查看库存服务异常如何影响整个链路
- 每个 Span 都有唯一的 Span ID，通过 Trace ID 关联
- 时间条越长，表示该服务耗时越长
4.2 معيار OpenTelemetry
OpenTelemetry (OTel) هو المعيار الصناعي لتتبع الروابط، ويوفر API و SDK موحدين.
javascript
// مثال: استخدام OpenTelemetry لتسجيل Span
import { trace } from '@opentelemetry/api'
const tracer = trace.getTracer('my-service')
async function processOrder(orderId) {
// إنشاء Span
const span = tracer.startSpan('processOrder')
try {
// تعيين الخصائص
span.setAttribute('order.id', orderId)
// منطق الأعمال...
await validateOrder(orderId)
await saveToDatabase(orderId)
span.setStatus({ code: SpanStatusCode.OK })
} catch (error) {
span.recordException(error)
span.setStatus({ code: SpanStatusCode.ERROR, message: error.message })
} finally {
span.end() // إنهاء Span
}
}نقطة أساسية: تتبع الروابط يمكنه تحديد اختناقات الأداء ونقاط الفشل بسرعة، وهو أداة ضرورية للخدمات المصغرة.
5. سير عملية استكشاف الأخطاء
الأعطال الإنتاجية لا مفر منها، المفتاح هو الاستجابة السريعة والتعافي السريع.
5.1 سير معالجة الأعطال
故障响应流程 (Incident Response)
专业团队如何处理线上故障
1
故障发现
T+0 分钟
监控系统自动发现异常指标
关键动作：
- 监控检测到订单服务错误率从 0.1% 飙升到 8.5%
- Alertmanager 立即触发 P1 告警
- 值班人员收到钉钉和短信通知
常用工具：
PrometheusGrafanaAlertmanager
2
快速响应
T+3 分钟
值班人员确认故障并启动应急流程
3
故障定位
T+8 分钟
通过日志和追踪系统分析根因
4
故障修复
T+18 分钟
实施临时解决方案恢复服务
5
恢复验证
T+21 分钟
确认服务完全恢复正常
6
故障复盘
T+48 小时
总结经验教训，制定改进计划
🎯 故障处理最佳实践
快速响应
建立 15 分钟响应机制，P0 故障立即电话通知
信息同步
定期向用户和内部同步故障进展，避免猜测
保留现场
故障现场数据（日志、监控）完整留存，便于分析
blameless 文化
复盘对事不对人，聚焦流程改进而非个人责任
5.2 أدوات الاستكشاف الشائعة
| الأداة | الاستخدام | السيناريوهات النموذجية |
|---|---|---|
| tcpdump | تحليل التقاط الحزم | انقطاع الشبكة، فقدان حزم البيانات |
| strace | تتبع استدعاءات النظام | تجمد العملية، مشاكل صلاحيات الملفات |
| Arthas | تشخيص Java | ارتفاع CPU، تسرب الذاكرة، deadlock |
| top/htop | مراقبة موارد النظام | ارتفاع استخدام CPU/الذاكرة |
| netstat | عرض اتصالات الشبكة | احتلال المنافذ، عدد اتصالات غير طبيعي |
| lsof | عرض الملفات المفتوحة | ملف محتجز، امتلاء القرص |
مثال على Arthas (أداة تشخيص Java مفتوحة المصدر من Alibaba):
bash
# عرض أعلى 5 خيوط استخداماً لـ CPU
$ top -H -p 12345
# عرض زمن استدعاء دالة معينة
$ trace com.example.OrderService createOrder
# عرض الحقول الثابتة للفئة
$ getstatic com.example.Config MAX_CONNECTIONS
# تحديث الكود مباشرة (بدون إعادة تشغيل)
$ mc /tmp/Test.java
$ redefine /tmp/Test.class5.3 مراجعة ما بعد العطل (Post-mortem)
المراجعة ليست جلسة محاسبة!
الغرض من المراجعة هو:
- توثيق الخط الزمني للعطل
- اكتشاف السبب الجذري (Root Cause Analysis)
- استخلاص الدروس المستفادة
- وضع إجراءات التحسين
طريقة تحليل 5 Why:
اسأل "لماذا" 5 مرات على الأقل للوصول إلى السبب الجذري:
- لماذا تعطلت الخدمة؟
- لأن الذاكرة فاضت
- لماذا فاضت الذاكرة؟
- لأن بيانات التخزين المؤقت كانت كثيرة جداً
- لماذا كانت بيانات التخزين المؤقت كثيرة جداً؟
- لأنه لم يتم تعيين وقت انتهاء صلاحية
- لماذا لم يتم تعيين وقت انتهاء صلاحية؟
- لأنه تم إغفاله أثناء التطوير
- السبب الجذري: نقص في مراجعة الكود وحالات الاختبار
نقطة أساسية: بناء ثقافة blameless، التركيز على تحسين العمليات بدلاً من المسؤولية الفردية.
6. تحسين الأداء
6.1 تحليل اختناقات الأداء
نهج التحسين من الأعلى إلى الأسفل:
إدراك المستخدم
↓
تحسين الواجهة الأمامية (تقليل الطلبات، CDN، التحميل الكسول)
↓
تحسين الشبكة (HTTP/2، الضغط، الاتصالات المستمرة)
↓
تحسين الخلفية (التخزين المؤقت، غير المتزامن، المعالجة بالدفعات)
↓
تحسين قاعدة البيانات (الفهارس، تحسين الاستعلامات، التقسيم)
↓
تحسين النظام (معلمات النواة، ضبط JVM)6.2 تحسين قاعدة البيانات
تحسين الفهارس:
sql
-- استعلام بطيء (بدون فهرس)
SELECT * FROM orders WHERE user_id = 12345;
-- إنشاء فهرس يجعله أسرع بـ 100 مرة
CREATE INDEX idx_user_id ON orders(user_id);تحسين الاستعلامات:
sql
-- ❌ تجنب SELECT *
SELECT * FROM users WHERE id = 123;
-- ✅ استعلم فقط عن الحقول المطلوبة
SELECT id, name, email FROM users WHERE id = 123;
-- ❌ تجنب كثرة IN في الجملة
SELECT * FROM orders WHERE user_id IN (1, 2, 3, ..., 10000);
-- ✅ استخدم JOIN أو الاستعلام بالدفعات
SELECT * FROM orders o JOIN user_ids u ON o.user_id = u.id;6.3 تحسين التخزين المؤقت
هندسة التخزين المؤقت متعدد المستويات:
ذاكرة التخزين المؤقت للمتصفح (CDN)
↓
التخزين المؤقت المحلي (الذاكرة/Guava)
↓
التخزين المؤقت الموزع (Redis/Memcached)
↓
قاعدة البيانات (MySQL/PostgreSQL)استراتيجيات تحديث التخزين المؤقت:
| الاستراتيجية | المزايا | العيوب | السيناريوهات المناسبة |
|---|---|---|---|
| Cache-Aside | بسيطة وموثوقة | أول استعلام بطيء | قراءة كثيرة وكتابة قليلة |
| Write-Through | اتساق جيد للبيانات | كتابة بطيئة | قراءة وكتابة متوازنتان |
| Write-Behind | كتابة سريعة جداً | احتمال فقدان البيانات | كتابة كثيرة وقراءة قليلة، تحمل عدم اتساق قصير |
نقطة أساسية: التخزين المؤقت ليس رصاصة فضية، يجب مراعاة مشاكل الاتساق والانهيار والاختراق (راجع فصل "تصميم التخزين المؤقت للنظام").
7. تخطيط السعة
7.1 تقييم السعة
容量规划计算器 (Capacity Planning)
估算系统需要多少台服务器才能满足需求
📊 业务指标
人
次
%
次/秒
倍
💡 通常高峰期流量是平均流量的 2-3 倍，建议预留 50-100% 冗余应对突发流量
📈 容量评估结果
日均总请求量
5,000,000 次/天
高峰期 QPS (目标)
75 次/秒
理论所需服务器
1 台
推荐配置 (含冗余)
2 台
💰 月成本估算 (云服务器)
🎯 容量规划要点
以峰值为核心
不能按平均流量规划，必须按高峰期流量（通常是平均的 2-3 倍）来准备
预留冗余空间
至少预留 50% 冗余，用于应对突发流量、服务器故障、维护窗口
定期压测验证
每季度进行压力测试，验证实际容量是否满足预估
弹性扩缩容
结合云服务的自动扩缩容，在高峰期自动增加实例
📐 计算公式
日均请求量：DAU × 人均请求次数
平均 QPS：日均请求量 ÷ 86400 秒
高峰 QPS：平均 QPS × 高峰系数 (2-3 倍)
所需服务器：高峰 QPS × 冗余系数 ÷ 单机 QPS
7.2 اختبار الضغط
اختيار الأدوات:
| الأداة | الخصائص | السيناريوهات المناسبة |
|---|---|---|
| JMeter | قوي، مع واجهة مرئية | اختبار ضغط واجهات HTTP |
| wrk/ab | خفيف، سطر أوامر | اختبارات قياس سريعة |
| Locust | سكريبتات Python، موزع | اختبار ضغط سيناريوهات معقدة |
| K6 | حديث، سكريبتات JS | تكامل CI/CD |
مثال على wrk:
bash
# تثبيت wrk
$ brew install wrk # macOS
$ apt install wrk # Ubuntu
# اختبار ضغط لواجهة HTTP (10 خيوط، لمدة 30 ثانية)
$ wrk -t10 -c100 -d30s http://example.com/api/users
# الناتج:
# Running 30s test @ http://example.com/api/users
# 10 threads and 100 connections
# Thread Stats Avg Stdev Max +/- Stdev
# Latency 45.32ms 12.45ms 120.50ms 87.56%
# Req/Sec 2.12k 123.45 3.45k 89.01%
# 632450 requests in 30.00s, 1.23GB read
# Requests/sec: 21081.677.3 التوسع والانكماش المرن
التوسع والانكماش التلقائي في عصر السحابة الأصلية:
yaml
# Kubernetes HPA (Horizontal Pod Autoscaler)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70عندما يتجاوز استخدام CPU نسبة 70%، يتم توسيع الـ Pods تلقائياً (بحد أقصى 10)
نقطة أساسية: اجمع بين توقعات الأعمال (مثل مهرجان التسوق 11.11) للتوسع المسبق، لتجنب عدم اللحاق.
8. العمليات الأمنية
8.1 التحكم في الوصول
مبدأ الصلاحيات الدنيا:
- يمكن للمطورين الوصول إلى بيئة التطوير فقط
- يمكن لموظفي العمليات الوصول إلى بيئة الإنتاج فقط، وبموافقة مسبقة
- العمليات الحساسة على قاعدة البيانات تتطلب تأكيداً ثانوياً
خادم القفز (Jump Server):
تتم جميع عمليات التشغيل من خلال خادم القفز، مع تسجيل سجل كامل للعمليات.
8.2 النسخ الاحتياطي للبيانات
مبدأ النسخ الاحتياطي 3-2-1:
- 3 نسخ من البيانات (نسخة أصلية + نسختان احتياطيتان)
- 2 وسائط تخزين مختلفة (قرص محلي + تخزين سحابي)
- 1 نسخة احتياطية خارج الموقع (لمنع كارثة النقطة الواحدة)
استراتيجيات النسخ الاحتياطي:
| النوع | التردد | مدة الاحتفاظ | RTO | RPO |
|---|---|---|---|---|
| نسخ احتياطي كامل | أسبوعي | شهر واحد | 4 ساعات | 24 ساعة |
| نسخ احتياطي تزايدي | يومي | أسبوع واحد | ساعتان | ساعة واحدة |
| نسخ احتياطي فوري | كل ثانية | 7 أيام | دقائق | ثوانٍ |
RTO (Recovery Time Objective): هدف وقت التعافي (أقصى مدة لانقطاع الخدمة) RPO (Recovery Point Objective): هدف نقطة التعافي (أقصى كمية بيانات يمكن فقدانها)
8.3 فحص الثغرات
فحص دوري:
- فحص الكود: SonarQube و ESLint (اكتشاف الثغرات المحتملة)
- فحص التبعيات: npm audit و Snyk (اكتشاف ثغرات المكتبات الخارجية)
- فحص الحاويات: Trivy و Clair (اكتشاف ثغرات الصور)
bash
# مثال على npm audit
$ npm audit
found 3 vulnerabilities (1 moderate, 2 high)
Package Severity Vulnerable versions
lodash high <4.17.21
express moderate 4.0.0 - 4.18.2
# إصلاح تلقائي
$ npm audit fix9. العمليات الآلية (DevOps)
9.1 خط أنابيب CI/CD
yaml
# مثال على .gitlab-ci.yml
stages:
- test
- build
- deploy
test:
stage: test
script:
- npm install
- npm test
tags:
- docker
build:
stage: build
script:
- docker build -t myapp:$CI_COMMIT_SHA .
- docker push registry.example.com/myapp:$CI_COMMIT_SHA
only:
- main
deploy:
stage: deploy
script:
- kubectl set image deployment/myapp myapp=registry.example.com/myapp:$CI_COMMIT_SHA
environment:
name: production
when: manual # تشغيل النشر يدوياً9.2 البنية التحتية ككود (IaC)
مثال على Terraform (إدارة الموارد السحابية):
hcl
# main.tf
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
tags = {
Name = "WebServer"
Env = "production"
}
}
resource "aws_security_group" "web" {
name = "web-sg"
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
}المزايا:
- ✅ التحكم بالإصدارات: جميع الإعدادات في Git
- ✅ قابلية التكرار: اتساق البيئات
- ✅ قابلية التدقيق: سجل تغييرات واضح
- ✅ قابلية التراجع: استعادة سريعة للإصدارات السابقة
9.3 ممارسة GitOps
GitOps = Git + IaC + Automation
المفهوم الأساسي: مستودع Git هو المصدر الوحيد للحقيقة للبنية التحتية
سير العمل:
1. تعديل ملفات الإعدادات (push إلى Git)
↓
2. تغيير مستودع Git يشغّل CI/CD
↓
3. تنفيذ تلقائي لـ terraform apply/kubectl apply
↓
4. تحديث تلقائي للبنية التحتية
↓
5. مراقبة ومقارنة الحالة الفعلية بالحالة المرغوبةالأدوات: ArgoCD و Flux (لنشر Kubernetes)
10. ملخص وأفضل الممارسات
العمليات نظام ضخم، لكن يمكن تلخيص جوهره كالتالي:
10.1 نموذج نضج العمليات
| المستوى | الخصائص | الممارسات |
|---|---|---|
| مبتدئ | استجابة سلبية، عمليات يدوية | المعالجة فقط عند حدوث مشكلة، نشر يدوي |
| متوسط | أتمتة، توحيد المعايير | CI/CD، مراقبة وتنبيهات، توثيق |
| متقدم | الوقاية أولاً، التعافي الذاتي | تخطيط السعة، تمارين الأعطال، توسع وانكماش تلقائي |
| خبير | ذكي، بدون تدخل بشري | AIOps، هندسة الفوضى، Serverless |
10.2 يوم في حياة مهندس عمليات
09:00 - مراجعة تنبيهات الليل، تأكيد حالة النظام
10:00 - معالجة المشكلات المبلغ عنها من المستخدمين
11:00 - حضور اجتماع التطوير الأسبوعي، تقييم مخاطر تشغيل الحلول الجديدة
14:00 - تحسين الاستعلامات البطيئة، رفع الأداء
15:00 - مراجعة الكود (Code Review)
16:00 - كتابة وثائق النشر، تحديث قواعد المراقبة
17:00 - تمارين الأعطال (Chaos Engineering)
18:00 - تسليم المناوبة10.3 خارطة طريق التعلم
مرحلة المبتدئ (1-3 أشهر):
- تعلم أوامر Linux الشائعة
- فهم نظام المراقبة (Prometheus + Grafana)
- إتقان استعلام السجلات (ELK)
مرحلة المتوسط (3-6 أشهر):
- فهم عميق لتقنية الحاويات (Docker + K8s)
- إتقان أداة تشخيص (Arthas، tcpdump)
- ممارسة خط أنابيب CI/CD
مرحلة المتقدم (6-12 شهراً):
- ضبط الأداء (قاعدة البيانات، JVM، الشبكة)
- تخطيط السعة وتحسين التكلفة
- مراجعة ما بعد العطل وتحسين العمليات
مرحلة الخبير (أكثر من سنة):
- تصميم الهندسة المعمارية (التوفر العالي، التعافي من الكوارث)
- هندسة الفوضى (حقن الأعطال بشكل استباقي)
- AIOps (العمليات الذكية)
11. جدول المصطلحات (Glossary)
| المصطلح | الاسم الكامل | الشرح |
|---|---|---|
| Monitoring | - | المراقبة، مراقبة حالة تشغيل النظام في الوقت الفعلي. |
| Alerting | - | التنبيه، إخطار الأشخاص المعنيين عند حدوث خلل. |
| Logging | - | السجلات، تسجيل الأحداث أثناء تشغيل النظام. |
| Tracing | - | تتبع الروابط، تتبع المسار الكامل للطلب في النظام الموزع. |
| QPS | Queries Per Second | عدد الطلبات في الثانية، مقياس لإنتاجية النظام. |
| Latency | - | التأخير، الزمن من إرسال الطلب حتى استلام الرد. |
| RTO | Recovery Time Objective | هدف وقت التعافي، أقصى مدة لانقطاع الخدمة. |
| RPO | Recovery Point Objective | هدف نقطة التعافي، أقصى كمية بيانات يمكن فقدانها. |
| Post-mortem | - | مراجعة ما بعد العطل، تحليل أسباب العطل وإجراءات التحسين. |
| CI/CD | Continuous Integration/Delivery | التكامل المستمر والتسليم المستمر، أتمتة الاختبار والنشر. |
| IaC | Infrastructure as Code | البنية التحتية ككود، إدارة الخوادم والشبكات والموارد عبر الكود. |
| GitOps | - | عمليات Git، مستودع Git هو المصدر الوحيد للحقيقة للبنية التحتية. |
| ELK | Elasticsearch + Logstash + Kibana | ثلاثية جمع وتخزين وعرض السجلات. |
| SLA | Service Level Agreement | اتفاقية مستوى الخدمة، توفر الخدمة الموعود (مثل 99.9%). |
| Blameless | - | ثقافة اللاتوجيه، مراجعة تركز على تحسين العمليات بدلاً من المسؤولية الفردية. |
12. قراءة موسعة
- تصميم التخزين المؤقت للنظام - مبادئ وأنماط وأفضل ممارسات التخزين المؤقت
- تصميم طوابير الرسائل - تفريغ الذروة والفصل غير المتزامن
- مبادئ المصادقة والتطبيق العملي - المصادقة والتفويض وتعزيز الأمان
- تاريخ تطور الخلفية - من التطبيق الأحادي إلى الخدمات المصغرة إلى Serverless
- النشر والإطلاق - الكيلومتر الأخير من التطوير إلى الإنتاج