Logo GH

כחול-ירוק וקנרית משחררת

(סעיף: ארכיטקטורה ופרוטוקולים)

1) למה אנחנו צריכים ”התפרצויות בטוחות”

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

2) הגדרות בסיסיות

כחול ־ ירוק

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

קנרית

אנו מתגלגלים בחלקים: תחילה לאחוז קטן מהתנועה (לדוגמה, 1-5%), מתבוננים במדדים/SLO, ואז צעד אחר צעד מגדילים את הנתח (10% -25% -50% -50% -100%). בזמן ההשפלה - גלגול חוזר או לעצור בצעד היציב הקודם.

3) מתי הגישה הטובה ביותר

כחול-ירוק - בחר אם:
  • אנו זקוקים לחזרה מיידית ללא תמרונים מורכבים.
  • ארכיטקטורה/תקציב מאפשר כפילות תשתית כפולה.
  • אנחנו רוצים לבצע נדידה בקנה מידה גדול או עדכוני פלטפורמה (מערכת ההפעלה/JDK/runtime) בבידוד.
  • בריכות יישום/חיבור רגישות למצב ”מעורב” הדרגתי.
קנרית - בחר אם:
  • אתה צריך למזער את רדיוס הפיצוץ ולראות את ההתנהגות על נתח המשתמשים.
  • קצב שחרור גבוה, משלוח מתקדם כרגיל.
  • ישנן יכולת תצפית בוגרת ושערים אוטומטיים (תקציב שגיאה, latency, המרה).
  • צוות המוצר רוצה לבדוק השערות: השפעה על המרה, שימור, LTV וכו '.

4) עקרונות כלליים לשחרור מוצלח

אידמפוטנט לבנות חפצים: אותה תמונה/חבילה בכל השלבים.
תצורה דטרמיניסטית: הגדרה כקוד, השוואה של סביבות.
יכולת תצפית לפי עיצוב: יומנים, מדדים, עקבות, התראות; SLI/SLO מראש.
גלגול מהיר ואוטומטי: כפתור ההחזרה/פקודה הוא חלק מהצינור, לא קסם ידני.
סכימת התאמה משתנה: אסטרטגיית הרחבת-הגירה-חוזה (ראו § 10).
ניתוב L7 (רצוי): גמישות על כותרות API/עוגיות/שבילים/גרסאות.

5) כחול ־ ירוק: ארכיטקטורה ותהליך

5. טופולוגיה 1

שתי ערימות פרוד: כחול (פעיל) וירוק (מועמד).
תלות חיצונית נפוצה: CDN, API חיצוני, תורים; DB הוא מקרה מיוחד (ראו # 10).
נקודת החלפה: מאזן/כניסה/שער.

5. 2 זרימה של צעד אחר צעד

1. אנחנו מגדלים את גרין תחת חפץ חדש (VNext), אנחנו עורכים בדיקות עשן.
2. הפעלה אוטומטית נגד גרין (e2e, חוזה, רגרסיה).
3. לחמם את המטמון/הפעלות (אם ישים), לסנכרן דקירות רקע/תורים.
4. החלפת תנועה לירוק: היפוך אטומי (DNS TTL נמוך, החלפת כביש/Listener, משקל אינגרס = 100%).
5. אנו צופים ב-SLO בדקות/שעות הראשונות (אותות זהב: איחור, שגיאות, רוויה + מדדים עסקיים).
6. במקרה של בעיות - חזרה מיידית לבלו (להעיף בחזרה).

5. 3 יתרונות/חסרונות

רולבק מיידי, מודל מנטלי פשוט, בידוד טהור.
חסרונות: הכפלת תשתיות, קושי עם רכיבים מדינתיים ונדידת נתונים.

6) ארכיטקטורה ותהליך קנריים

6. טופולוגיה 1

אשכול ייצור יחיד; מספר גרסאות של השירות (יציב וכנרי) מאחורי חזית אחת.
התנועה מחולקת על ידי משקולות (1-5-10-25-50-100%) או על ידי מטרות (על ידי כותרת/עוגייה/זיהוי).

6. 2 זרימה של צעד אחר צעד

1. הפעל גרסאות קנריות לאותו אשכול/ASG/NSG.
2. נתיב תנועה מסוימת (לדוגמה, 1-5%) לקנרית.
3. בדיקות אוטומטיות של SLI/SLO ומדדים עסקיים; שערים ב CI/CD (שיעור שגיאה, p95 latency, CPU/RES, המרה, סירוב/חזרה).
4. עלייה של צעד אחר צעד בנתח התנועה כאשר עוברים שערים.
5. העלאה מלאה ל-100% וניטרול הגרסה הישנה; במקרה של הידרדרות - אוטומטית-rollback.

6. 3 יתרונות/חסרונות

יתרונות: סיכון מינימלי לרוב המשתמשים, פתרון מונע נתונים.
חסרונות: אנחנו צריכים תצפית בוגרת, ניתוב מוכשר, הסיכון של ”גירסה מרופדת” בין מקרים.

7) ניתוב תנועה

שכבה L4: איזון באמצעות IP/ports; פשוט, אבל מעט גמישות.
רמה L7: חוקי HTTP/S - על הנתיב, מארח, כותרת, עוגיות, משתמש-סוכן, GeoIP, SNI.

טכנאים:
  • ניתוב משוקלל (משקולות 1-100%).
  • מבוסס על כותרת/עוגיות.
  • דבקות בהפעלה (חשוב לתסריטים סטטיסטיים/מטופחים).
  • שיקוף צל/תנועה (המראה מבקשת את הגרסה החדשה ”בשקט”).

8) כלים ויישומים (דוגמאות)

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.
AWS ALB/ELB, כביש 53 משוקלל, ECS/EKS; GCP Load Mazancing + NEG; Azure דלת קדמית/אפליקציה שער.
פלטפורמות CD: Spinnaker, Argo CD, GitHub Actions + Progressive Deliverse Plugins, GitLab/CD.

💡 עיקרון ראשון: גירסה - קוד, תנועה - מדיניות, קידום - שערי SLO אוטומטיים.

9) יכולת תצפית, SLI/SLO ושערים

אותות זהב: Latency (p95/p99), Error rate (5xx/4xx), RPS, Saturation (CPU/Memory/GC), Quue lag.
מדדים עסקיים: המרה, אישורים, תשלומים/הצלחות, סימון ממוצע, סירוב על ידי צעדים משפטיים.

שערים:
  • סף שגיאה (לדוגמה, שגיאה מדרגת את קו הבסיס הקנרי + X%).
  • p95 latency אינו גרוע יותר מקו בסיס על ידי יותר מנטל.
  • סף העסקים (למשל: הטלת המרה
  • תקציב שגיאות SLO לא צריך להישרף מהר יותר.

משך שלב: זמן מינימלי מספיק למשמעות סטטיסטית (תלוי בתנועה).

10) נדידת מסד נתונים ותאימות סכימה

הכלל העיקרי: שחרורים בטוחים אם הגרסאות הלוך ושוב מתאימות.

אסטרטגיית הרחבת חוזה ההגירה:

1. התרחב: הוסף טורים חדשים/אינדקסים/טבלאות מבלי לשבור את הגרסה הישנה.

2. פריסת אפליקציית vNext (קורא/כותב לתכנית החדשה, אבל יודע איך לעבוד עם הישן).

3. מידע נודד (רקע/אצווה, אידמפוטנטי, עם נקודות ביקורת).

4. חוזה: מחק שדות/תכונות ישנות לאחר הייצוב.

אנטי-דפוסים: נדידה הדורשת חסימה בלעדית בנקודה של מתג כחול-ירוק; חוסר יכולת להוריד את הדירוג; ”כתיבה כפולה” ללא שכפול.

11) רולבק ותוכניות חירום

כחול-ירוק: להעיף מיידי על כחול; לפקח על הזנבות של עבודות רקע ירוקות.
קנרית: rollback (לדוגמה, מ-25% חזרה ל-5% או 0%); ביטול אוטומטי על התראות.
נתונים: מדיניות שחושבת היטב על חזרה/פיצוי (מפתחות אידמפוטנטיות, תבנית ”inbox/outbox”, שכפול מסרים).
מתג חיסול מהיר לכבות הזדמנויות מגולגלות חלקית.

12) עבודה עם המדינה והפגישות

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

13) בטיחות וציות

גישה לירוק/קנרית - על ידי אפס נאמנות: חשבונות שירות, מינימום תפקידים נדרשים.
סודות ומפתחות - באמצעות מנהל KMS/סודות; תדליק את הסיבוב.
תנועה - TLS בלבד; הגרסאות הסופיות מסומנות בבירור; ביקורת פעולות ניתוב ושחרור.

14) עלות וביצועים

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

15) רשימות בדיקה

לפני השחרור

[ ] תמונה/בנייה מקודמת ממקור אחד, חתימות מאומתות.
[ תוכנית מבחן ], התראות ושערי SLO מוגדרים.
[ נדידת מסד הנתונים ] - במצב התרחבות, תוכניות הורדת דירוג זמינות.
[ ] תוכנית רולבק - בדק היערכות/ייצור דמוי.

בעת השחרור

[ ] מטריצות ויומנים מושווים לקו הבסיס.
[ ] לקנריים, המדרגות והסף קבועים; עבור מוכנות כחולה-ירוקה.
[ ] הפקודות התורניות נמצאות בידיעה, יש חלון משוב.

לאחר השחרור

[ ] SLO לא שקע, תקציב שגיאות הוא נורמלי.
[ ] נדודים/ניקוי שלאחר השחרור הושלם.
[ ] רטרוספקטיבה ועדכון מהלכים.

16) שגיאות תכופות ותבניות אנטי

אין נתונים - אין פתרון מנוהל.
ערבוב מזימות בסיס נתונים לא מתאימות, חוסר אסטרטגיה הורדה.
ערבוב תנועה אקראי: ללא דבקות, משתמשים ”לקפוץ” בין גרסאות.
תלויות סטטוטוריות נסתרות (דיסקים מקומיים, מטמונים בזיכרון).
Long DNS-TTL מפריע עם סלטה מהירה (Blue-Green).
חוסר אוטוגנטים: פתרונות ”בעין” ידניים מאטים ומגבירים סיכונים.

17) גישות משולבות

כחול ירוק + קנרי: רול החוצה ירוק ראשון, אז בתוך ירוק לגלגל את קנרית עבור שירותים בודדים.
צל/תנועה נודדת: לפני קנרית, אנו מריצים תנועה משוקפת לגרסה החדשה.
דגלי תכונה (progressive deliversity): פונקציונליות נכללת על גבי הגרסה היציבה על ידי דגלים ”כהים” על ידי מקטעים.

18) תרחישי דגימה (סקיצות)

כחול-ירוק (אינטרנט + api):

1. פרוס ירוק (v2) עבור המאזין/אינגרס החדשה.

2. לחמם את המטמונים, לבצע בדיקות מחדש, לעשן.

3. אנחנו מחליפים את המשקל לירוק = 100%.

4. התבונן SLO במשך 30-60 דקות; אם הכל בסדר - לכבות כחול.

קנרית (מיקרו-רוויס תשלום):

1. פרוס Canary Vest (העתק 5%).

2. אנחנו כוללים 5% תנועה לחשבונות פנימיים/קטע בדיקה.

3. אוטוגט: תקצב שגיאה את קו הבסיס + 0. 3%, p95 + 20 ms.

4. אנחנו מעלים 10% פי 25% -50% כל N דקות כאשר עוברים שערים.

5. אנחנו מתרגמים פישפלאג 100% לכל המקטעים; מוחק את הגרסה הישנה.

19) וריאציות לארכיטקטורה שונה

מונולית ': Blue-Green הוא פשוט יותר, Canary הוא קשה יותר בשל חוסר ההתאמה של תכונות; תשתמש בפישפלאגים.
מיקרו-רווחים: הקנרית טבעית; צג חוזים המונעים על ידי צרכנים.
שירותים מדינתיים: מעדיף כחול-ירוק עם נדידות מעוצבות בקפידה ודביקות.

20) השוואה קצרה (סיכום)

Rollback מהירות: כחול-ירוק = מיידי; קנרית = מהר אבל עם פולק במשקל.
עלות התשתית: כחול-ירוק; ↔︎/↓ הקנריים.
סיכון למשתמשים: הקנריים נמוך יותר (אנחנו שולטים בנתח).
קושי ביישום: כחול-ירוק קל יותר להתחיל; קנרית דורשת תצפית חזקה ואוטומציה.
תאימות נתונים/מעגל: קריטי עבור שניהם; תוכנית להרחיב-להגר חוזה.

21) השורה התחתונה

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

Contact

צרו קשר

פנו אלינו בכל שאלה או צורך בתמיכה.אנחנו תמיד כאן כדי לעזור.

Telegram
@Gamble_GC
התחלת אינטגרציה

Email הוא חובה. Telegram או WhatsApp — אופציונליים.

השם שלכם לא חובה
Email לא חובה
נושא לא חובה
הודעה לא חובה
Telegram לא חובה
@
אם תציינו Telegram — נענה גם שם, בנוסף ל-Email.
WhatsApp לא חובה
פורמט: קידומת מדינה ומספר (לדוגמה, +972XXXXXXXXX).

בלחיצה על הכפתור אתם מסכימים לעיבוד הנתונים שלכם.