استلام منصة Production قائمة: ماذا تصلح في أول 90 يومًا؟

استلام مسؤولية Production Platform موجودة مختلف تمامًا عن Greenfield Project.

النظام عنده Users وRevenue وOperational Habits وTechnical Debt وIntegrations وDeployment History وافتراضات غير موثقة.

ما ينفعش توقف كل شيء لحد ما Engineering Team تعيد رسم Architecture.

وبرضه ما ينفعش تفترض إن أسوأ Code في نظرك هي أكبر مشكلة للBusiness.

أول مهمة مش Modernization.

أول مهمة هي تقليل عدم اليقين.

قبل ما تغيّر النظام، خليه مفهوم. قبل ما تسرّعه، خلّي Failure مرئية. وقبل Rewrite، افهم ليه وصل للشكل الحالي.

Playbook مفيدة لأول 90 يوم:

Days 1–30  → Understand & Stabilize
Days 31–60 → Control & Simplify
Days 61–90 → Improve & Prepare to Scale

الأيام مش Deadlines جامدة. Incident كبيرة ممكن تغير الأولويات فورًا. المهم ترتيب التفكير.

ما تبدأش بـRewrite

Technical Leader جديدة غالبًا هتلاقي Code ما كانتش هتكتبها بنفس الشكل.

ده مش دليل إن Platform محتاجة Rewrite.

Existing Code فيها سنين من Business Decisions وEdge Cases وOperational Knowledge. جزء منها ممكن يكون سيئ فعلًا، وجزء شكله سيئ لأن Constraint الأصلية اختفت من الذاكرة.

Rewrite مبكرة تخلق منصتين في نفس الوقت: Production System ما زالت تحتاج Support، وReplacement System تستهلك Engineering Capacity.

اعمل Rewrite فقط لما Evidence تقول إن Incremental Change مش قادرة تحل Constraint الحقيقية بشكل معقول.

أول يوم: حدد Critical Business Paths

ما تبدأش بقراءة كل Repository سطر سطر.

ابدأ بالProduct.

أنهي Workflows لازم تشتغل علشان Business تشتغل؟

في SaaS ممكن تكون:

Sign up
→ Authentication
→ Subscription/payment
→ Core product action
→ Notifications/integrations
→ Reporting

في Marketplace: Search، Order، Payment، Fulfilment، Refund.

في Learning Product: Authentication، Content Delivery، Progress، Quizzes، Subscription State.

المبدأ واحد:

Technical Priority تبدأ من Business-critical Flows.

Admin Page بطيئة مش زي Authentication تفشل بشكل متقطع.

اعمل System Map قبل Architecture Diagram

Architecture Diagram أحيانًا ترسم اللي الناس فاكرة إنه موجود.

System Map لازم ترسم اللي فعليًا داخل Production.

اعمل Inventory للApplications/Services، Databases، Cache، Queues/Workers، Storage، Search، Scheduled Jobs، External APIs، Payments، Auth Providers، Email/SMS/Push، Analytics، Monitoring، CI/CD، Cloud Accounts، DNS/CDN/WAF، Secrets وConfiguration Sources.

وبعدين Dependencies:

Mobile/Web
   ↓
API/Application
   ↓
DB · Cache · Queue · Storage
   ↓
Workers / Integrations
   ↓
External providers

أنت بتدور على Hidden Single Points of Failure وHidden Ownership.

افهم Code بتوصل Production إزاي

من أول الأسئلة:

إيه اللي بيحصل بالضبط من Merge لحد ما User تستقبل التغيير؟

Commit
→ CI
→ Tests
→ Build
→ Deploy
→ Migrations
→ Health checks
→ Traffic
→ Monitoring

لو فيه Steps Manual سجلها. لو Person واحدة تعرف Secret Deployment Step دي Risk. لو Migrations بدون Visibility دي Risk. لو Rollback مجرد Theory دي Risk.

مش لازم Automate كل شيء في Week 1. لازم تعرف الخطر فين.

Observability قبل Optimization

ما ينفعش Stabilize Platform من User Complaints فقط.

لازم تعرف: Application Healthy؟ أنهي Endpoints/Jobs بتفشل؟ إيه اللي اتغير قبل Failure؟ Queries بتبطأ؟ Queue بتتراكم؟ Workers بتقع؟ External Providers Timeout؟ أنهي Version شغالة؟ المشكلة Global ولا Isolated؟

Signals المفيدة عادة Application Errors، Structured Logs، Request Latency، Database Health، Queue Depth/Age، Worker Failures، Infrastructure Metrics وDeployment Markers.

ما تجمعش Telemetry علشان Dashboard شكلها Professional. اجمعها علشان تساعد حد ياخد Decision.

Alerts لازم تمثل Action

Alert محدش فاهمها أو بيتصرف عليها تتحول Noise.

لكل Alert مهمة: إيه Trigger؟ ليه مهمة؟ مين Owner؟ يفحص إيه أولًا؟ إمتى Escalate؟

Alert Quality أهم من Alert Quantity.

اقرأ Incident History

Past Incidents أسرع طريق لفهم Mature Platform.

دور على Patterns: DB Saturation، Queue Backlog، Memory Exhaustion، Third-party Failures، Deployment Regressions، Data Inconsistency، Expired Credentials، Storage Limits، Slow Queries، Race Conditions، Cache Failures.

ما تسألش “إيه اللي وقع؟” فقط.

اسأل: ليه System قدرت توصل للحالة دي بدون Detection أوContainment بدري؟

الإجابة غالبًا تكشف Fix أعلى Leverage من Bug نفسها.

افصل Symptoms عن Constraints

Slow Endpoint عرض. Constraint ممكن تكون Unindexed Query أوN+1 أوExternal API في Request Path أوLock Contention أوOversized Payload.

High Cloud Cost عرض. Constraint ممكن Idle Resources أوInefficient Queries أوOverprovisioning أوLogs مكلفة أوNetwork Traffic.

ما تحطش Roadmap Item اسمها “Improve Performance” بدون Constraint محددة.

افهم Data قبل تغيير Code

في Established Platform، Database أحيانًا فيها Truth أكثر من Documentation.

راجع Largest Tables، Growth لو Data متاحة، Indexes، Slow Queries، Integrity Assumptions، Soft Deletes، JSON Fields، Cleanup، Retention، Backups وMigration History.

Clean Refactor تتجاهل Data Shape ممكن تسوء Production.

Backup مش كفاية؛ Verify Recovery

“Backup Successful” مش نهاية القصة.

اعرف إيه اللي بيتعمل له Backup، Frequency، Retention، Storage، مين يقدر Restore، Current Procedure، وهل Restore اتجرب فعلًا.

الهدف Recoverability، مش Backup نظرية.

Security: أصلح Exposure قبل Architecture Elegance

راجع Concrete Risks: Shared Credentials، Secrets في Repo، Excessive Production Access، Missing MFA، Public Services، Critical Unpatched Dependencies، Weak Authorization، Missing Audit Trails وOverpowered API Tokens.

Service Decomposition جميلة ما تعوضش Exposed Production DB.

Map Ownership مش Technology فقط

حدد Owner للCritical Areas:

Authentication → owner
Payments       → owner
Mobile API     → owner
Infrastructure → owner
Data pipeline  → owner
Notifications  → owner

Ownership مش معناها شخص واحد يلمس Code. معناها حد مسؤول يفهم Health وChanges وRisks.

Team جزء من Architecture

افهم Requirement بتتحول Engineering Work إزاي، مين يقرر Priority، حجم Work Items، Reviews، QA، Releases، Production Bugs وRequirements Unclear قد إيه.

Delivery Problem مش دائمًا Developer Performance Problem. Bottleneck ممكن تكون Requirements أوOwnership أوReviews أوQA أوDependencies أوDeployment أوArchitecture.

Days 1–30: الناتج Risk Map

مش Bug List فقط.

Risk / constraint
Business impact
Evidence
Current owner
Immediate containment
Longer-term fix
Confidence

بدل “Codebase سيئة”، Engineering تقدر تقول: Queue دي بتأخر Critical Workflow تحت Load؛ دي Evidence، وده Containment، وده Proposed Fix.

ده Technical Leadership قابلة للتنفيذ.

Days 31–60: Control & Simplify

بعد ما Risks تظهر، المرحلة الثانية تجعل Production Changes أكثر أمانًا وتزيل Recurring Friction.

أصلح Repeat Offenders أولًا

ما ترتبش Technical Debt حسب Ugly Code.

رتب المشاكل اللي تكرر Incidents، Customer Impact، Delivery Delay، Security Exposure، Operating Cost أوManual Work.

Reliability Fix مملة ممكن تعمل Business Value أكثر من Architecture Project مثيرة.

اعمل Safe Deployment Baseline

الهدف: Normal Change لازم تكون مملة في Release.

حسن أضعف نقاط Automated Tests، Static Analysis، Reproducible Builds، Environment Config، Migration Safety، Health Checks، Deployment Visibility، Rollback/Roll-forward وFeature Flags عند الحاجة.

ما تطاردش Perfect CI/CD Diagram. شيل أخطر Uncertainty أولًا.

حط Critical Workflows تحت Tests

Thousands of Tests ممكن ما تحميش Paths المهمة. وقلة Tests ممكن تخلي Team خايفة تغير أي شيء.

ابدأ من Risk: Critical Workflows، Authorization، Money Logic، Data Transformations وBugs خرجت Production.

Test Count مش الهدف. Confidence to Change هي الهدف.

قلل Production Access

لو Engineers تدخل SSH أوتعدل Production Data يدويًا باستمرار، اسأل ليه.

Emergency Access أحيانًا ضرورية، لكن Manual Intervention المتكرر غالبًا Missing Tooling.

استبدل Operations المتكررة بـControlled Commands، Admin Workflows، Audited Jobs أوDeployment Automation.

خلي Safe Path أسهل من Dangerous Path.

خلّي Background Work مرئية

راقب Pending Work، Age of Oldest Job، Failure Rate، Retry Behavior، Worker Health وProcessing Latency.

100 Job ممكن تكون Healthy لو بتخلص في Seconds. 10 Jobs ممكن تكون Broken لو Oldest منتظرة Hours.

حط Limits حول External Dependencies

أي Third-party API جزء من Production System.

حدد Timeouts، Retries، Rate-limit Handling وFailure Behavior.

لو Provider اختفت 5 دقائق أوساعة أو يوم: User Request تفشل؟ Work تتQueue؟ Product تشتغل Degraded Mode؟

Optional Integration ما تتحولش Accidental Single Point of Failure.

شيل Hidden Synchronous Work

Pattern شائعة:

User Request
→ DB writes
→ Third-party API
→ Email
→ Analytics
→ Document generation
→ Response

جزء منها ممكن Async لما Business Semantics تسمح.

لكن Queue تحتاج Idempotency وRetry Safety وObservability. Async Architecture تبدل Problems بأخرى؛ اعمل Trade deliberately.

Optimize Queries بالEvidence

ما تضيفش Indexes عشوائيًا.

حدد Expensive/High-frequency Queries، اقرأ Execution Plans، افهم Data Distribution، وبعدها غير Indexes/Access Patterns.

Performance Work لازم Evidence-driven.

اربط Technical Debt بالRoadmap

بدل Backlog اسمها Technical Debt تتحول Graveyard، اربط Debt بـBusiness Outcome:

Debt: synchronous provider call
Impact: checkout fails when provider is slow
Work: decouple non-critical step
Outcome: checkout no longer depends on provider latency

كده Product Leadership تفهم ليه الشغل مهم.

Standardize Incident Learning

للIncidents المهمة سجل What happened، User/Business Impact، Timeline، Detection، Contributing Factors، Containment، Why not detected earlier، Follow-ups وOwners.

ما تحولش Postmortem للبحث عن Engineer نلومها. Systems تتحسن لما Team تقدر تكشف Failure بصراحة.

Days 31–60: الناتج Control

دلوقتي Platform أسهل في الفهم: تعرف إيه Deployed، تشوف Failures المهمة، Ownership أوضح، Constraints معروفة، وRoutine Changes أكثر أمانًا.

دي Foundation للArchitecture Changes الأكبر.

Days 61–90: Improve & Prepare to Scale

بعد Stabilization فقط ابدأ Structural Decisions أكبر.

Architecture Roadmap من Measured Constraints

اسأل: أنهي DB Limit هتضرب أولًا؟ أنهي Service لها Scaling Profile مختلفة؟ أنهي Queue تحتاج Partitioning؟ أنهي Dependency تحتاج Decoupling؟ أنهي Table تحتاج Archival؟ أنهي Module أعلى Change Risk؟ أنهي Infrastructure Spend غير مبرر؟

ده Roadmap من Constraints حقيقية مش Architecture Fashion.

ما تقسّمش Monolith لمجرد إنها Monolith

Large Laravel App مش مشكلة تلقائيًا، وMicroservices مش Scalability تلقائيًا.

Split Boundary بسبب Independent Scaling أوReliability Requirement أوSecurity Boundary أوSeparate Ownership أوRuntime Requirement أوDomain تحتاج Independent Deployment.

غير كده، Modularizing Existing App ممكن تكون أرخص وأأمن.

Capacity Planning تبدأ من Workload Shape

“هل النظام يستحمل 10M Users؟” سؤال ناقص.

Registered Users مختلفة تمامًا عن Concurrent Load.

قيس Concurrent Users، RPS، Read/Write Ratio، Queue Throughput، Peak/Average، Data Growth، Storage Growth، Expensive Endpoint Frequency وExternal API Quotas.

Scale الـWorkload مش Marketing Number.

Load-test Critical Paths

Homepage ترجع 200 تحت Load مش دليل لو Bottleneck الحقيقية Booking Creation أوCheckout أوProgress أوReport Generation.

اختبر Realistic Important Flows وراقب App + DB + Cache + Queues + Dependencies.

الهدف اكتشاف First Constraint بأمان قبل Customers.

Reliability Targets تناسب Business

مش كل Admin Screen تحتاج Reliability زي Authentication أوPayments.

حدد Critical Capabilities وService Indicators مفيدة: Successful Auth، Successful Order، API Latency، Job Completion Time.

Targets تساعد Team تعرف إمتى Reliability Work تتقدم على Feature Work.

Cost Optimization بعد Attribution

قبل “AWS غالية” أو“ننقل Cloud”، افهم Cost جاية منين: Compute، DB، Storage، Network، Logs، Third-party Services وWorkloads.

Optimize Expensive Constraint. نقل Inefficient Workload لـCloud ثانية ممكن ينقل Invoice فقط.

قرر إيه يتModernize وإيه تسيبه

Keep: Stable low-risk code تعمل شغلها.

Improve: Areas مهمة Incremental Refactoring تقلل Risk فيها.

Replace: Components Constraints بتاعتها لا تتحل معقول Incrementally.

Retire: Features/Services لم تعد تبرر Operational Cost.

عدم لمس Stable Legacy Code أحيانًا Architecture Decision.

Engineering Scorecard للقرارات

اختار Metrics قليلة تعكس Delivery وProduction Health: Critical Incidents، Deployment Health، Change Failure، Critical Endpoint Errors/Latency، Queue Health، DB Saturation، Blocked Work وInfrastructure Cost Trends.

Metrics لازم تعمل Questions وActions، مش Performance Theatre.

Roadmap على Horizons

Now

Risks ممكن تضر Users/Business اليوم.

Next

Structural Improvements تقلل Recurring Delivery/Operational Cost.

Later

Scale/Modernization justified by Growth.

ده يمنع Long-term Architecture تخفي Immediate Reliability، ويمنع Urgent Bugs تستهلك كل Future Investment.

اتكلم Business Language

بدل “لازم Refactor للQueue Architecture”، قول إن Workflow حاليًا ممكن تتأخر لما External Provider تبطأ، وDecoupling تقلل Dependency وتدي Controlled Retries.

بدل “Database Schema سيئة”، اشرح Table بتعمل Measurable Query Pressure على Critical Workflow وإيه Change اللي هتختبر تأثيرها.

Architecture Technical. Prioritization Business.

عايز إيه بحلول Day 90؟

مش Perfect Platform. مش Rewrite كاملة. مش Zero Technical Debt.

عايز System/Dependency Map موثوقة، Critical Business Flows واضحة، Actionable Observability، Top Risks وOwners، Safer Deployment Path، Protection للCritical Workflows، Recovery مفهومة ومختبرة، Manual Operations أقل، Evidence عن Performance/Scale Constraints، وTechnical Roadmap مرتبطة بـBusiness Impact.

الأهم: Decisions أقل مبنية على Guessing.

أول 90 يوم هدفهم تكسب الحق في التغييرات الأكبر

لما تستلم Large Production Platform، Architecture Opinions تظهر فورًا. Evidence تحتاج وقت.

أول Phase تبني Visibility وOperational Control كفاية علشان Big Decisions تصبح Defensible.

الترتيب اللي أفضل أشتغل به:

Understand
→ Observe
→ Stabilize
→ Control
→ Measure
→ Improve
→ Scale

مش:

Arrive
→ Rewrite

أفضل أول 90 يوم مش اللي تخلي Platform شكلها أحدث؛ هي اللي تخلي الـ900 يوم اللي بعدها أكثر أمانًا في البناء.

استلمت SaaS أوProduction Platform موجودة وعايز تثبت Delivery وArchitecture وInfrastructure بدون ما توقف Business؟

أشتغل مع Product وEngineering Teams على Platform Takeovers وTechnical Leadership وArchitecture وProduction Reliability وModernization، ونحوّل Unknown Technical Risk إلى Evidence-based Roadmap.

---

مرتبط: Engineering Leadership، Custom Software Development، Technical Debt، وWhy Software Projects Are Late When Engineers Are Busy.