DevGuide 🇵🇸

دردشة سريعة عن وظيفة Site Reliability Engineer ⚡️
.
.
زمان (قبل ما يظهر مصطلح SRE)، لما أي شركة كانت تبني سيستم كبير – مثلًا web app أو service فيها ملايين الـ Users – كان فيه دايمًا فصل واضح بين فريقين:

1- الـ Developers: الناس اللي بتكتب الكود وتضيف Features جديدة.
2- الـ Operations / SysAdmins: الناس اللي مسؤولة عن تشغيل السيستم، الـ monitering، الـ servers، الـ uptime، إلخ.

والفريقين دول كانوا في حرب مستمرة دايمًا، الـ Developer عايز يـ release features بسرعة ويريح دماغه، والـ Ops عايز السيستم يفضل ثابت، علشان كده بيكره أي تغييرات مفاجئة.

وطبعًا ده هيأثر على البيزنس بشكل عام وعلى طبيعة الشغل في الشركة وهنا تدخلت جوجل وعملت وظيفة جديدة اسمها Site Reliability Engineer

———

📌 يعني إيه SRE؟

ببساطة، الـ Site Reliability Engineering هو طريقة لتطبيق مبادئ الـ Software Engineering على مشاكل الـ Operations.
يعني بدل ما تعتمد على manual work، نخلي كل حاجة automated، measured، ومبنية على data واقعية.

الـ SRE Engineer بيكون في النص بين الـ Developers والـ Ops. هو مهندس فاهم المنظومة كلها من أول الكود لحد الـ production.

———

⚙️ شغل الـ SRE مقسم لحاجتين أساسيتين:

1- الـ Reliability: يتأكد إن السيستم شغال بثبات، مفيش downtime، وكل حاجة monitored.
2- الـ Velocity: يتأكد إن الـ teams تقدر تـ deploy بسرعة وآمان بدون ما النظام يبوظ.

———

💡 بعض المفاهيم الأساسية في عالم الـ SRE:

1. SLI / SLO / SLA
- الـ SLI (Service Level Indicator): مقياس لأداء السيستم، زي مثلًا latency أو availability.
- الـ SLO (Service Level Objective): الهدف اللي عايزين نحافظ عليه، زي إن الـ uptime يكون 99.9%.
- الـ SLA (Service Level Agreement): الاتفاق اللي الشركة بتديه للعملاء، ولو كسرته ممكن يحصل penalties.

الـ SRE بيتابع الـ SLI عشان يتأكد إننا داخل الـ SLO، ولو قربنا نكسره بيوقف أي تغييرات لحد ما الدنيا تستقر.

——

2. Error Budget
بدل ما تمنع التغيير تمامًا، خلي فيه ميزانية للأخطاء عن فريق الـ Development. مثلًا، لو الـ SLO بتاعك 99.9%، يبقى عندك 0.1% downtime مسموح بيه.
لو لسه الميزانية دي موجودة: ممكن تـ deploy features.
لو خلصت: توقف كل حاجة لحد ما النظام يستقر.

——

3. Monitoring & Alerting
الـ SRE بيبني أنظمة monitoring ذكية تـ detect المشاكل قبل ما المستخدم يحس بيها. وبيعمل alerts مبنية على الـ SLO مش على noise. يعني مش كل Warning تبقى Alert.

——

4. Incident Management
لما الدنيا تقع، الـ SRE بيقود عملية الـ incident response ويحدد المشكلة، ويصلحها، وبعدها يعمل حاجة اسمها Postmortem — تحليل بعد المشكلة عشان يتفادى تكرارها.

——

5. Automation
كل حاجة ممكن يتعملها automation:

- deployment
- scaling
- recovery
- testing
- monitoring

———

💯 المهارات اللي لازم تكون عند أي SRE محترم:

- فهم عميق للـ Linux systems
- خبرة في Cloud platforms (AWS / GCP / Azure)
- معرفة قوية بـ Networking و Load Balancing
- أدوات زي Prometheus, Grafana, Kubernetes, Terraform, Jenkins
- مهارات في Scripting (Python / Bash / Go)
- وأهم حاجة: problem-solving و communication skills ممتازة.

———

وفقكم الله لكل خير 🌿

❤8

www.tgoop.com/the_developer_guide/5703

586 viewsOct 10 at 16:11

دردشة سريعة عن وظيفة Site Reliability Engineer ⚡️
.
.
زمان (قبل ما يظهر مصطلح SRE)، لما أي شركة كانت تبني سيستم كبير – مثلًا web app أو service فيها ملايين الـ Users – كان فيه دايمًا فصل واضح بين فريقين:

1- الـ Developers: الناس اللي بتكتب الكود وتضيف Features جديدة.
2- الـ Operations / SysAdmins: الناس اللي مسؤولة عن تشغيل السيستم، الـ monitering، الـ servers، الـ uptime، إلخ.

والفريقين دول كانوا في حرب مستمرة دايمًا، الـ Developer عايز يـ release features بسرعة ويريح دماغه، والـ Ops عايز السيستم يفضل ثابت، علشان كده بيكره أي تغييرات مفاجئة.

وطبعًا ده هيأثر على البيزنس بشكل عام وعلى طبيعة الشغل في الشركة وهنا تدخلت جوجل وعملت وظيفة جديدة اسمها Site Reliability Engineer

———

📌 يعني إيه SRE؟

ببساطة، الـ Site Reliability Engineering هو طريقة لتطبيق مبادئ الـ Software Engineering على مشاكل الـ Operations.
يعني بدل ما تعتمد على manual work، نخلي كل حاجة automated، measured، ومبنية على data واقعية.

الـ SRE Engineer بيكون في النص بين الـ Developers والـ Ops. هو مهندس فاهم المنظومة كلها من أول الكود لحد الـ production.

———

⚙️ شغل الـ SRE مقسم لحاجتين أساسيتين:

1- الـ Reliability: يتأكد إن السيستم شغال بثبات، مفيش downtime، وكل حاجة monitored.
2- الـ Velocity: يتأكد إن الـ teams تقدر تـ deploy بسرعة وآمان بدون ما النظام يبوظ.

———

💡 بعض المفاهيم الأساسية في عالم الـ SRE:

1. SLI / SLO / SLA
- الـ SLI (Service Level Indicator): مقياس لأداء السيستم، زي مثلًا latency أو availability.
- الـ SLO (Service Level Objective): الهدف اللي عايزين نحافظ عليه، زي إن الـ uptime يكون 99.9%.
- الـ SLA (Service Level Agreement): الاتفاق اللي الشركة بتديه للعملاء، ولو كسرته ممكن يحصل penalties.

الـ SRE بيتابع الـ SLI عشان يتأكد إننا داخل الـ SLO، ولو قربنا نكسره بيوقف أي تغييرات لحد ما الدنيا تستقر.

——

2. Error Budget
بدل ما تمنع التغيير تمامًا، خلي فيه ميزانية للأخطاء عن فريق الـ Development. مثلًا، لو الـ SLO بتاعك 99.9%، يبقى عندك 0.1% downtime مسموح بيه.
لو لسه الميزانية دي موجودة: ممكن تـ deploy features.
لو خلصت: توقف كل حاجة لحد ما النظام يستقر.

——

3. Monitoring & Alerting
الـ SRE بيبني أنظمة monitoring ذكية تـ detect المشاكل قبل ما المستخدم يحس بيها. وبيعمل alerts مبنية على الـ SLO مش على noise. يعني مش كل Warning تبقى Alert.

——

4. Incident Management
لما الدنيا تقع، الـ SRE بيقود عملية الـ incident response ويحدد المشكلة، ويصلحها، وبعدها يعمل حاجة اسمها Postmortem — تحليل بعد المشكلة عشان يتفادى تكرارها.

——

5. Automation
كل حاجة ممكن يتعملها automation:

- deployment
- scaling
- recovery
- testing
- monitoring

———

💯 المهارات اللي لازم تكون عند أي SRE محترم:

- فهم عميق للـ Linux systems
- خبرة في Cloud platforms (AWS / GCP / Azure)
- معرفة قوية بـ Networking و Load Balancing
- أدوات زي Prometheus, Grafana, Kubernetes, Terraform, Jenkins
- مهارات في Scripting (Python / Bash / Go)
- وأهم حاجة: problem-solving و communication skills ممتازة.

———

وفقكم الله لكل خير 🌿

BY DevGuide 🇵🇸