תפקידי צוות התשתית

1) התמונה המלאה: מדוע להתמחות

חיזוי ומהירות: בעלים ברורים מפחיתים ”אזורים אפורים”.
אמינות וביטחון: חלוקת אחריות על ידי תחומים (K8s, רשתות, DB, אבטחה).
כלכלה: FinOps מפריד בין ערך לצריכה ומנהל את ”מחיר התשיעיות”.
התנסות מפתחת: פלטפורמה כמוצר - שירות עצמי, תבניות, קטלוגים.

2) תפקידי מפתח ואחריות

3) גבולות של אחריות (גבולות של בעלות)

הפלטפורמה היא בעלת רמת שירותי פלטפורמה L3-L7 (K8s, רשת, יכולת תצפית), אך לא לוגיקה עסקית.
SRE הוא הבעלים של תהליך האמינות (SLO/generation/post-mortems) ולא של כל צוות מוצר ספציפי.
שחרור/משלוח הוא בעלים של המכניקה של החישובים, אבל האחריות ל ”מה” מוטלת על פקודות התכונה.
חברת DBRE מחזיקה במדיניות אשכולות/נתונים, והסכימה/הגירות נמצאות בבעלות צוות המוצר (לפי תקני DBRE).
SecOps הבעלים של מדיניות ושליטה, ויישום משותף עם בעלי דומיין.

4) מודלים מבצעיים

1. פלטפורמה מרכזית - התחלה מהירה, סיכון צוואר בקבוק.
2. פלטפורמה כמוצר (PAP) - תבניות שירות עצמי, קטלוגים, ”שוק פנימי” של שירותים.
3. פדרציה/גילדות - מומחים מוטמעים בתחום המוצרים (פרק/מוטבע SRE/DBRE).
4. מטריקס - סטנדרטים אסטרטגיים של המרכז + ביצוע בתחומים.

המלצה: לשלב PaAP לצרכים בסיסיים ומוטבע עבור תחומים קריטיים.

5) ממשקים ו ־ OLAs (הסכמים פנימיים)

ספריית שירות: מה זמין ”כשירות” (K8s name space, אשכול נתונים, תור, לוח מחוונים SLO, פרופיל התראה).
אולא (הסכם רמה תפעולי): תאריכי תגובה, זירות אחריות, נקודות הסלמה.
כרטיסי SLO של שירותי פלטפורמה: זמינות, latency API, זמן פריסה מהתבנית.

yaml service: "Kubernetes Namespace Provisioning"
owner: "Platform"
request_channel: "Service Catalog"
targets:
response_time: "≤ 15 min"
delivery_time: "≤ 1 hour (without manual approvals)"
scope:
includes: "quota, RBAC, secrets integration"
excludes: "business configs, database migrations"
escalation: "#plat-ops-oncall"

6) רסי: מי עושה מה

אגדה: ר - מבצע, א - מגיב, ג - ייעוץ, אני - מעודכן.

7) KPIs ומדדי ביצועים לפי תפקיד

פלטפורמה: זמן הובלה למתן שירות, שירות עצמי%, NPS Devex.
SRE: MTTR/MTTD, הוצאה להורג של SLO, כיסוי חוברות משחקים, שיתוף אוטומטי.
Ops/NetOps: Uptime היקפי, changey runtime, תקריות הגדרה.
DBRE: RPO/RTO, הצלחת שחזור, lag שכפול p95.
שחרור: אחוז משוחררי הקנרית, שיעור הרולבים, זמן הסביבה.
תצפית: שלמות של אותות, זמן תגובה של בקשות/לוחות מחוונים, יחס נגד רעש.
זמן סגירה עבור CVS קריטי, תקריות אבטחה MTTD/MTTR, כיסוי מנהל סודי.
FinOps: עלות לכל שירות/RPS, חיסכון נכון, חיזוי דיוק.

8) עלייה למטוס ודווקס

חבילת התחלה: Terraform/Helm תבניות, צינורות CI/CD, ”Hello, Service” checklists.
פורטל עגינה: סטנדרטים, דוגמאות, לוחות מחוונים חיים, כפתורי שירות עצמי.
סדנאות/שעות עבודה: לפי תפקיד (SRE 101, SecOps 101, DBRE 101).
מדיניות הסלמה: למי להתקשר בלילה ומתי כרטיס זה מספיק.

9) גבולות הבעלות והגישה של הנתונים

ביטוח IAM: בעלי תפקידים, חיי גישה, גישה (just-in-time).
סודות: מנהל סודי מרכזי, סיבוב, איסור על סודות ב-ENV/repo.
בעלות על נתונים: המוצר הוא הבעלים של סכימה/נתונים של התחום; DBRE הוא הבעלים של ”כלי שיט” (אשכולות ומדיניות).

10) תהליכים: תקריות, שינויים, משחררים

תקריות: IC/war-room/לאחר המוות (ראו תקריות וספרי משחק).
ניהול שינוי: סיכון מבוסס, נתיב מהיר לסיכון נמוך, CAB לסיכון גבוה בלבד.
שחרור: משלוח מתקדם, הקפאת כללים בעת שריפת טעויות תקציב.

11) רשימת בדיקות לפי תפקיד (לחץ)

פלטפורמה

[ ] ספריית שירות ו SLA עבור כל שירות פלטפורמה

[ ] IAC + Policy Templates (OPA/Confest)

SRE

[ ]-SLO-קלפים של נתיבים עליונים, התראות קצב צריבה, ספרי משחק

[ ] דו "ח תקציב שגוי חודשי

DBRE

[ ] תרגילי DR, בדיקת התאוששות, RPO/RTO חתום

[ ] מדיניות ההגירה והאינדקס

secOps

[ ] מיון נקודות תורפה וחלונות תיקון

[ ] בקרות DLP/PII, ביקורת נגישות

לשחרר

[ ] מדרגות קנרית ברירת מחדל,

[ ] דגלים מאפיינים ומתג להרוג

תצפית

[ ] Metrics/Label Standards, לוח מחוונים תקציבי

[ ] נגד רעש (מניין, חלון מרובה), וידג 'טים SLO

FinOps

[ ] Chargeback/showback, ימינה המלצות

[ ] ”עלות לכל 9”, חיזוי

12) דפוסי אנטי-ארגון

”DevOps הוא אדם”: עומס יתר של ”גנרליסטים”, מחסור בבעלי תחומים.
”פלטפורמה = משרד כרטיסים”: כל דרך כרטיסים ידניים, ללא שירות עצמי.
”SRE = כבאים בתפקיד”: ללא SLO וסמכות.
”אבטחה כסטופקוק”: הכללה מאוחרת יותר, במקום ”מעקות בטיחות לפי עיצוב”.
”תצפית = גרפים יפים”: ללא התראות-פעולה ו-SLOs.
"FinOps רק על הדו" ח ": ללא המלצות וצדק אוטומטי.

13) תבניות חפץ

תבנית כרטיס שירות פלטפורמה

yaml service: "Managed PostgreSQL"
owner: "DBRE"
plan: "S, M, L"
slo:
availability: "99. 95 %/quarter"
rpo: "≤ 5 min"
rto: "≤ 15 min"
interfaces:
request: "Service Catalog → Postgres"
incidents: "#dbre-oncall"
changes: "Change Policy L2"
security:
secrets: "Vault"
access: "JIT/RBAC"
finops:
pricing: "по vCPU/GB/IOPS"
limits: "quota per tenant"

mini RACI לשחרור

yaml release:
strategy: canary
R: Release/Delivery
A: Product Owner
C: SRE, SecOps
I: Platform

14) תוכנית יישום (4 איטרציות)

1. תקן (2-3 שבועות): מפת תפקידים, קטלוג שירות, RACI, OLAs, ערוצי הסלמה.
2. דווקס (3-4 שבועות): קטלוג שירות, תבניות CI/CD, מודולי Terraform, לוחות SLO/dashboard בסיסיים.
3. אמינות ואבטחה (4-6 שבועות): מחזות תקריות, תרגילי DR, WAF/DLP, מנהל סודי.
4. FinOps ו-Optimization: chargback, rightsizing, ”עלות לכל 9”, מדיניות אוטומטית.

15) מיני ־ FAQ

איפה להשאיר את SRE בפלטפורמה או במוצרים?
היברידי: SRE אסטרטגי בפלטפורמה, משובץ SRE בתחום קריטי.

מי הבעלים של שירותי SLO?
צוותי מוצרים. SRE מספק מתודולוגיה, כלים ובקרת תהליכים.

איך להימנע מ ”צל את זה”?
קטלוג שירות, OLA מפורש, שירות עצמי מהיר ותמחור שקוף (showback/chargback).

סך הכל

פונקציית תשתית חזקה היא תפקידים ברורים + גישת מוצר לפלטפורמה + סכימות על ממשקים ומדדים. לכידת RACIs ו-OLAs, מתן שירות עצמי וסטנדרטים, מדידת ביצועים מול KPIs של כל תפקיד, ושיפור קבוע של DevEX, SLO ועלות. זה יפחית סיכונים מבצעיים, יאיץ שחרור ויהפוך את התשתית לחיזוי.