قصة عميل · Rawda Health
اجتازت Rawda Health مراجعة الأمان في أسبوع، ورصدت عطلاً حقيقياً عصر اليوم نفسه
احتاج فريق بيانات في قطاع الرعاية الصحية إلى مراقبة لا تقترب من بيانات المرضى أبداً.
- للربط
- 20 دقيقة
- تنبيهات أقل للفرز
- 70%
- من مراجعة الأمان إلى الإنتاج
- أسبوع واحد
المشكلة
تدير Rawda Health شبكة من 46 عيادة للرعاية الأولية في الإمارات والسعودية. ويعدّ فريق البيانات فيها، المؤلف من أربعة أشخاص، تقارير عن المواعيد وأوقات الانتظار والتوظيف انطلاقاً من قاعدة بيانات تشغيلية على Postgres تُنسخ إلى Snowflake.
جرّب الفريق قبل ذلك أداتين للمراقبة، وكانت كلتاهما تريد أخذ عينات من محتوى الجداول. وهذا يعني خروج بيانات المرضى من مستودع البيانات، في حين يجب أن تبقى البيانات الصحية في الإمارات داخل الدولة كقاعدة عامة. فتعثّرت مراجعتا الأمان كلتاهما. وفي الأثناء كانت التنبيهات تأتي من ثلاثة أماكن، ولا أحد مسؤول عنها.
ما الذي تغيّر
تقرأ Tessel البيانات الوصفية وسجلات التشغيل والشيفرة، ولا تقرأ نتائج الاستعلامات أبداً، وتخزّن تلك البيانات الوصفية في منطقتها داخل دولة الإمارات. راجع فريق الأمان في Rawda تقرير SOC 2 من النوع الثاني (تجريبي)، ومخطط تدفق البيانات، وملحق معالجة البيانات (DPA)، ووافق عليها خلال أسبوع.
ربطت أماني يوسف، قائدة فريق البيانات، كلاً من dbt Cloud وGitHub وSnowflake في 20 دقيقة. وفي عصر اليوم نفسه رصدت Tessel تحميلاً تزايدياً فاشلاً في نموذج المواعيد، وفتحت طلب دمج (pull request) لإصلاحه. وقلّص تجميع الحوادث التنبيهات التي يفرزها الفريق بنسبة 70%، وصارت المناوبة تعمل عبر PagerDuty مع مسؤول واضح لكل حادثة.
منظومة الأدوات: dbt Cloud، Postgres، Snowflake، GitHub، Slack، PagerDuty.
مراحل الإطلاق
-
الأسبوع الأول
مراجعة الأمان بالاستناد إلى تقرير SOC 2 ومخطط تدفق البيانات وملحق معالجة البيانات (DPA).
-
اليوم الأول للتشغيل
الربط خلال 20 دقيقة، وأول طلب دمج للإصلاح عصر اليوم نفسه.
-
الشهر الأول
توجيه الحوادث إلى المسؤولين عنها عبر PagerDuty، وانخفاض حجم التنبيهات بنسبة 70%.
استغرق الإعداد عشرين دقيقة، ورصد أول عطل حقيقي عصر اليوم نفسه.
احصل على النتيجة نفسها مع أدواتك
سنشغّل Tessel على نسخة من مشروعك خلال العرض التوضيحي، لترى حوادثك أنت.