The IDF's Journey to the Cloud (Hebrew) 20.06.2021

יש המשל למעטה.
Ниже есть продолжение.

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

מודול 1: הגרעון התרמודינמי ומגבלות החומרה

הארגון הצה"לי פועל כגרף מאקרו מורכב. מצד אחד, אנו מתמודדים עם מערכות מיושנות. מצד שני, סביבת הריצה שלנו מאוכלסת בתהליכים ביולוגיים צעירים (חיילים בני 18), שרגילים לאינטראקציה מיידית עם וקטורים חישוביים. קליק אחד של תהליך כזה יכול לאתחל מסד נתונים של MongoDB בעלות של 40,000 דולר, ולייצר אנטרופיה פיננסית, או לחלופין לשחרר פוינטרים חשופים שמסכנים את אבטחת המידע.

קיימת סטייה הולכת וגדלה (Offset) בין קצב איסוף המידע האקספוננציאלי לבין קיבולת העיבוד שלנו. נתקענו במחסום פאזה – תקרת בטון פיזית. חוות השרתים המקומית שלנו, "מצודת דוד", דרשה למעלה מ-10 שנות פיתוח ויותר ממיליארד שקלים. התצורה הפיזית הזו קרובה לגבול לנדאואר – היא אינה מסוגלת להתרחב במהירות הנדרשת. ניצולת ה-CPU בשרתים הפיזיים עומדת על 25%-40% בלבד, וזמן ההקצאה (Time to Market) לחומרה חדשה לוקח חודשים. מודל ה-Bare Metal מוביל ל-Underfitting ולהרעבת משאבים.

מודול 2: אסטרטגיית הענן העליונה (ZFC Mapping)

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

• המאקרו-מטמון הציבורי (Public Cloud): רדיאטור חומרתי חיצוני שמתעדכן במהירות. מיועד למערכות בסיווג נמוך (תומכי לחימה, מנהלה, שערי כניסה). אנו נמקסם את השימוש בו.
• מקטע הענן המבודד (Secured Cloud / Nimbus): סביבה ייעודית מנותקת-רשת (Air-gapped) המנוהלת תחת פרויקט נימבוס, ומיועדת לעיבוד נתונים מסווגים מבלי להפר את גבולות המערכת.
• הענן הפרטי (Private Cloud / On-Prem): הליבה הפיזית שלנו (OpenStack, OpenShift, VMware). לאור היעילות בענן הציבורי, אנו שואפים לצמצם סביבה זו כך שתכיל רק 10%-20% מהנתונים הקריטיים ביותר.

מודול 3: קומפילציה ואלוקציה (מיפוי ונימבוס)

המרנו את מצבי המערכת הקיימים לפעולות לוגיות. ביצענו סריקה מלאה של מערכות ה-Legacy, סיווגנו אותן והחלטנו אילו יעברו מיגרציה, אילו יעברו קונסולידציה ואילו יעברו דפרקציה (SIGKILL למערכות מיותרות). הוקמה תוכנית אגירה מסודרת באקסל. הצטרפנו לפרויקט נימבוס הממשלתי כדי לבנות סביבה מקומית בישראל. נכון לעכשיו, רוב הפעילות מבוצעת על תשתית Azure של Microsoft, אך אנו מעבדים את הפלטפורמה לתמיכה ב-3 עננים כדי למנוע Vendor Lock-in ולהבטיח יתירות.

הארכיטקטורה הציבורית אינה מקשה אחת. הפעלנו חלוקת זיכרון קפדנית (Micro-segmentation). פוינטר המכיל טופס דיווח מחלה אינו חולק את אותו מרחב זיכרון עם פוינטר של מערכת כוח אדם רגישה. הכל מנוהל דרך עמדות מאובטחות (VDI/Endpoints).

מודול 4: פרוטוקול CCoE (Cloud Center of Excellence)

כדי למנוע שגיאות סנכרון ו-Race Conditions, הגדרתי דימון-אב מרכזי: ה-CCoE. ה-DNA שלו מוזרק לכל הזרועות (אוויר, ים, מודיעין) המקימות CCoE מקומי משלהן. מודולי הליבה ב-CCoE הם:

• ארכיטקטורה ואבטחה: בניית גבולות גזרה, DevSecOps אוטומטי המחייב סריקת שורות קוד לפני אישור.
• הגירה (Migration): מחלקה ייעודית המתמרצת את הזרועות לאתחל את המעבר.
• הבטחת מידע (מכב"ם): פונקציה המוודאת מה מותר לשלוח לשרתים חיצוניים ומה מחויב להישאר על ה-Bare Metal.
• רכש (Vendor Management): ניהול הממשקים, חוזים והתחשבנות מול ספקי הענן.
• הדרכה (Training): קידוד מחדש של התהליכים הביולוגיים (החיילים). קורסי התכנות הישנים נמחקו; כעת מלמדים כתיבת קוד לענן. גם קצינים בכירים חויבו לעבור עדכון גרסה מושגי.
• ייעוץ משפטי: התמודדות עם רגולציה ופרטיות (מידע רפואי, נפגעים).
• כלכלת ענן (FinOps): מנגנון קריטי לשמירת משוואת התרמודינמיקה הפיננסית.

מודול 5: FinOps – שליטה באנטרופיה הכלכלית

שינינו את המודל התרמודינמי מתשלום מראש (CapEx) לתשלום על בסיס פעימות שעון (OpEx). אני משלמת רק על המשאב שהופעל. שרת שנשאר דולק בלילה יחויב, ולכן תהליכים יתומים צריכים להיות מחוסלים. איפשרנו רכישת Spot Instances ו-Reserved Instances. יצרנו מקצוע חדש בצבא: "כלכלן ענן".

הנחיות ה-FinOps נועדו למנוע Overfitting של הוצאות:

1. בדיקת ערך מבצעי טרם הקצאת משאב.
2. מדיניות ריכוזית עם אפשרות לגמישות מבוקרת בכל זרוע.
3. שקיפות מלאה למפקדים על צריכת התקציב.
4. שימוש בתיוג חובה (Tagging) למשאבים – כדי למנוע Memory Leaks ושרתים ללא בעלים. תהליך ללא Owner יקרוס.
5. קביעת תקרת תקציב למניעת חריגות אוטומטיות.
6. צמדי אחריות: איש כספים ואיש טכנולוגיה פועלים יחד לניטור קלט/פלט.

מודול 6: שאילתות וניהול חריגים (Q&A Dump)

חריג 1: אבטחת מידע (Security Fears)

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

חריג 2: טופולוגיות IaaS לעומת PaaS/SaaS

במעבר הראשוני, אנו מעבירים מערכות Legacy בתצורת IaaS (Lift & Shift), אך מעודדים את המפתחים לקמפל אותן מחדש ל-PaaS ולשרתים ללא מצב (Serverless) להורדת עלויות. בנוגע ל-SaaS – מופעל חסם (Firewall). פתרונות SaaS זרים מוציאים את הדאטה מגבולותינו, ולכן לרוב מסורבים מטעמי אבטחה, אלא אם יעברו תהליך זיכוי מחמיר במרקטפלייס ייעודי.

חריג 3: אינטגרציה רב-זרועית (Cross-Branch Consolidation)

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

חריג 4: שימוש בקוד פתוח (Open Source)

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

חריג 5: רגולציה ואבטחה מול חדשנות

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

חריג 6: אסטרטגיית Multi-Cloud

כדי למנוע נעילת ספק (Vendor Lock-in), אנו פועלים בתצורה רב-ממדית. לא נבצע חלוקה של תהליך בודד (אפליקציה) על פני שני עננים (כדי למנוע Latency וחיוב כפול על תעבורה), אך בהחלט נריץ מערכות שונות על Azure, AWS או Google בהתאם למקסום הפונקציה (Best of Breed). המהלך מבוצע לאט ובתשומת לב מרבית לתקציב ואבטחה.