הגדרת Hetzner Cloud: היכן ניהול ידני נכשל
הגדרת Hetzner Cloud דרך לוח הבקרה ומפגשי ssh עובדת בדיוק עד לסטייה הראשונה. בשבוע שעבר העלינו מכסות, הוספנו כלל בחומת האש, חיברנו דיסק ללוגים — בצ'אט כמה שורות, ובמאגר הקוד ריק. כעבור חודש מהנדס מפרס עותק בסביבת עומס ומקבל מערכת אחרת.
סחיפת קונפיגורציה היא תוצאה ישירה של ניהול שרתים ידני. סביבת העבודה וסביבת הבדיקות נבדלות בעשרה זוטות: גרסת ספרייה, סדר הפעלת שירותים, פרמטר ליבה שנשכח. כל אחת בנפרד לא מזיקה, אבל יחד זה כבר סביבה אחרת, וכל אבחון מתחיל בבדיקה "איך זה באמת אצלנו".
המחיר מתגלה ברגע הכשל. שחזור הסביבה הופך לארכיאולוגיה: להעלות מהזיכרון, לחפש מי ומתי שינה את כללי הרשת, לנחש אילו תעודות משויכות לכתובת הישנה. זמן ההשבתה נמדד בשעות, ואין לאף אחד ביטחון שהבנייה החדשה זהה לזו שאבדה — פשוט אין חזרה משוחזרת למצב הקודם.
הכשל השלישי מתנהג בשקט יותר מכולם: שינויים לא מתועדים לא צפים עד ביקורת או העברת הפרויקט לצוות אחר. ואז מתברר שחצי מההגדרות קיימות רק בראש של אדם אחד, ושגישה לתשתית יש לכל מי שאי פעם התחבר. נסביר איך זה נסגר.
מה נותנת תשתית דקלרטיבית: אפקטים מדידים
תיאור דקלרטיבי של הסביבה מסיר את מקור התקלות העיקרי — פער בין התיעוד לבין מה שבאמת פועל על השרתים. כל עוד התשתית נערכת בידיים דרך לוח הבקרה של Hetzner Cloud, כל שינוי חי בהיסטוריית ההפעלות של אחרים, ותקלה יש לנתח מהזיכרון. מקור אמת יחיד על הסביבה משנה את התמונה: מצב הסביבה הוא קובץ במאגר, והשרתים מיושרים אליו אוטומטית.
מהירות השחזור לאחר כשל
הסביבה עולה מחדש מהתיאור, ולא נבנית שלב-שלב לפי רשימת בדיקה. חזרה לאחר כשל של צומת או של אזור שלם אורכת עשרות דקות: נפרסת אותה קונפיגורציה שעבדה לפני הכשל, כולל כללי רשת, איזון עומסים וחיבור אחסון. חזרה למצב קודם היא חזרה לגרסה הקודמת של התיאור, ולא חיפוש הבדלים בלוגים. סוג הכשלים "שכחו פרמטר בעריכה ידנית" נעלם יחד עם העריכות הידניות עצמן.
יכולת שחזור של סביבות
מתיאור אחד עולים סביבת בדיקות, סביבת טרום-ייצור וסביבת ייצור — עם אותה טופולוגיית רשת ואותם כללי גישה. פערים בין סביבות מפסיקים להיות חידה: אם משהו עובד בבדיקות ולא עובד בפרודקשן, ההבדל נראה בתיאור, ולא מחפשים אותו ימים.
סביבה לבדיקת עומס או ללקוח נפרד נוצרת ונמחקת בשלמותה, בלי משאבים שנשכחו וממשיכים לעבוד ולדרוש תשומת לב.
לפי נתוני הענף DORA, בצוותים עם רמה גבוהה של אוטומציה השחזור אחרי אירוע נמדד בעשרות דקות, ומהירות החזרה למצב עבודה היא הגורם שמקצר ביותר את זמן ההשבתה.
גישות לניהול תשתית: השוואת מצבי ניהול
מצב הניהול קובע כמה עבודה ידנית דורש כל שינוי וכמה מהר הצוות מתאושש אחרי כשל. להלן ארבע אפשרויות שבהן באמת בוחרים בהגדרת Hetzner Cloud.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ניהול ידני | מערכים חד-פעמיים לניסוי | המצב לא מתועד, המערכים נבדלים, חזרה ידנית |
| תיאור דקלרטיבי | תשתית קבועה, כמה סביבות | נדרשת בקרת מצב וסקירת שינויים |
| בניית תמונות שרת | הרבה צמתים אחידים, עדכונים תכופים | התמונה נבנית מחדש בכל שינוי, השחרור ארוך יותר |
| מחזור אספקה רציפה | שחרורים תכופים, כמה צוותים | סף כניסה גבוה יותר: נדרשות בדיקות בענף ונראות |
מגבלות מצב ידני
מצב ידני נשען על הזיכרון של המבצע: שרת עם שינויים בקונפיגורציה לא ניתן לשחזר אחד לאחד, לכן הפער בין המערכים מצטבר חודשים ומתגלה ברגע הכשל. השחזור אחרי תקלה אורך שעות, והסיבה להגדרות הנוכחיות חיה בהתכתבות.
העלות של מעבר לתיאור דקלרטיבי
אפשר לעבור בחלקים: תחילה מתארים רשת, כללי גישה ושרתים, אחר כך בניית תמונות ואספקה. העלויות העיקריות הן ייבוא משאבים קיימים ומאגר מצב משותף; בהמשך כל שינוי נבדק לפני יישום, והסביבה עולה בשחזוריות ובאופן זהה.
סדר היישום: ביקורת, הגדרה, בדיקה, מסירה
היישום ב-Hetzner Cloud מתקדם באיטרציות: תחילה מתעדים את מצב הסביבה בפועל, אחר כך מעבירים אותו לתיאור, ורק לאחר מכן מפעילים בדיקות אוטומטיות. בכל שלב הסביבה נשארת פעילה — חזרה אפשרית כל עוד הסביבה החדשה לא אישרה שקילות.
ביקורת הסביבה הנוכחית
- ספירת מלאי: אוספים שרתים, רשתות, כרכים, רשומות DNS, תעודות, הרשאות ותלויות חיצוניות; פערים בין התיעוד למצב בפועל מוציאים כרשימה נפרדת.
- ביקורת קונפיגורציה: בודקים כללי חומת אש, הפרדת הרשאות, סבב מפתחות, מצבי גיבוי; מסמנים עריכות ידניות שלא ישרדו יצירה מחדש של המשאב.
- תוכנית הגירה: מפרקים את המעבר לקבוצות — מה מתארים כקוד מיד, מה נשאר ידני, באיזה סדר עוברות הסביבות; לכל שלב מגדירים נקודת חזרה.
בנייה, בדיקה ומסירה
- תיאור הסביבה כקוד: מודולי Terraform, הפרדת סביבות, מצב במאגר משותף עם נעילות, צפייה בתוכנית השינויים לפני יישום.
- צינור: בניית תמונה, בדיקות, פרסום לרישום, אספקה דרך סוכן GitOps; סודות מגיעים ממאגר סודות, ולא נמצאים במאגר הקוד.
- בדיקת קונפיגורציה: משווים את המצב בפועל למתואר ומריצים תרחישי כשל — אי-זמינות צומת, אובדן קשר עם מאגר המצב, תוכנית שגויה.
- מסירה לתפעול: נוהל שחרור וחזרה לאחור, ניטור והתראות, סדר חקירת אירועים, הכשרת הצוות והעברת הרשאות.
תוצרי היישום: קונפיגורציות, תרשימים, נהלים
בסיום נשאר לצוות הלקוח לא אוסף צילומי מסך מלוח הבקרה, אלא מאגר שממנו התשתית נפרסת מחדש מאפס. קונפיגורציות, תרשימים ונהלים מונחים לצד קוד האפליקציה, עוברים סקירה ומנוהלים בגרסאות — כל שינוי בסביבה נראה בהיסטוריה.
- תיאור תשתית — קונפיגורציה ב-Terraform: שרתים, רשתות, מאזני עומסים, אחסון וקשרים ביניהם.
- תרשים רשת — חלוקה למקטע פרטי וציבורי, תת-רשתות, נקודות יציאה לאינטרנט, כללי ניתוב.
- מדיניות גישה — תפקידים ומפתחות, הפרדה בין סביבת ייצור לסביבת ביניים, סדר הקצאה ושלילת הרשאות.
- נוהל שחזור — זמן יעד ונקודת שחזור, סדר עלייה מצילומי מצב, תפקידים בעת כשל.
- תיעוד הסביבות — במה נבדלים פרודקשן, סטייג' וסביבת בדיקות, אילו משתנים, סודות ומכסות הוגדרו.
- הוראות שחרור — איך עוברים בנייה ואספקה, היכן נקודות אישור ידני, איך להחזיר גרסה.
- תזכורת לתורנות — אירועים טיפוסיים ופעולות ראשונות לכל אחד.
תיעוד וסדר שחזור
הנוהל מתאר שחזור שלב-שלב: העלאת רשת, פריסת שירותים מהקונפיגורציה, בדיקה לאחר חזרה לאחור. מעדכנים אותו בכל שינוי בתשתית — אחרת כעבור חודש הוא נפרד מהמציאות. אחת לרבעון עורכים שחזור תרגולי באתר נפרד ומתעדים את הזמן בפועל.
מקרה בוחן: העברת שירות לתיאור דקלרטיבי של הסביבה
שירות משישה רכיבים חי על שרתים שנבנו ידנית בלוח הבקרה של Hetzner Cloud: הקונפיגורציה של כל סביבה הייתה קיימת רק בהיסטוריית הפעולות של המהנדס שהגדיר אותה.
כעבור חצי שנה סביבת הבדיקות הפסיקה להתאים לפרודקשן — פערים צפו כבר בשחרור, והעלאת סביבה חדשה ארכה שניים-שלושה ימים והייתה תלויה באדם אחד שזכר את סדר השלבים.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן העלאת סביבה | 2–3 ימים | 25 דקות |
| שיעור שחרורים ללא התאמות ידניות | 68% | 97% |
| אירועים בגלל אי-סנכרון בין סביבות | 5–6 ברבעון | 0–1 |
הסביבה הפכה לתוצאה של תיאור אחד: כאשר משתנה משתנה — רק הוא משתנה, ולא אוסף של עריכות ידניות שהתפזרו על פני שלוש סביבות. הרצה חוזרת על סביבה נקייה נותנת תוצאה זהה, ולכן "עובד אצלי מקומית" הפסיק להיות טיעון.
מה נתנה הפרדת הסביבות
הפרדנו את סביבת הייצור, טרום-הייצור והבדיקות לסטים נפרדים של תיאורים עם מודולים משותפים. הפער נראה כעת בשלב בדיקת השינויים, ולא בסביבת הייצור: ההבדל בקונפיגורציות מחושב אוטומטית ומגיע לסקירה.
החזרה לאחור מתבצעת על ידי יישום חוזר של התיאור הקודם — השחרור הפסיק להיות פעולה בלתי הפיכה, ומהנדס תורנות מחזיר גרסה עובדת בדקות, בלי שחזור מגיבוי.
שורה תחתונה: הכנת הסביבה התקצרה מימים לחצי שעה, ושיעור השחרורים שנדרשו להם התאמות ידניות אחרי הפריסה ירד פי שלושה.
מה לעשות אם התשתית כבר פרוסה ידנית?
סביבה שפרוסה ידנית לא דורשת עצירת השירות כדי לעבור לניהול לפי תיאור. הצעד הראשון הוא ספירת מלאי של משאבים: לאסוף שרתים, כרכים, רשתות פרטיות, מאזני עומסים, רשומות DNS, כללי חומת אש ומה שבאמת פועל בכל צומת.
חלק מהתמונה נראה דרך ה-API של הספק, וחלק — רק מהמכונות עצמן: יחידות systemd, משימות cron, מכולות, נקודות עיגון ותלויות חיצוניות שזוכר רק מי שהגדיר.
בהמשך — תיאור הסביבה הקיימת, לא הרצויה. אנחנו מתעדים את המצב הנוכחי כפי שהוא, כולל עריכות ידניות ומקומות מורכבים היסטורית, ומייבאים משאבים קיימים בלי ליצור אותם מחדש.
ייבוא תשתית קיימת קורא מזהים אמיתיים ומקשר אותם לקונפיגורציה — השירות ממשיך לעבוד, ותוכנית השינויים בשלב הזה נשארת ריקה. תוכנית ריקה היא הקריטריון העיקרי: היא מוכיחה שהתיאור תאם את המציאות, ורק אחר כך אפשר לשנות משהו.
הגירה מדורגת מתקדמת מהשוליים לליבה: תחילה מה שלא משפיע על תעבורה — צילומי מצב, רשתות, כללי גישה, אחר כך סביבות, ורק לאחר מכן צמתים תחת עומס. כל שלב נסגר בבדיקת תוכנית בלי יישום; פערים מטפלים בהם עד אפס, ורק אז השינויים עוברים לפרודקשן.
בנפרד מחליטים מה נשאר ידני: אחסון עם מצב מכניסים מאוחר יותר ובזהירות רבה יותר, כי מחיר הטעות שם גבוה מזה של צומת אינטרנט.
הביטוח בכל שלב הוא אותו דבר — צילום מצב טרי והיעדר שינויים בפרודקשן עד אישור מפורש. כך הסביבה עוברת לניהול לפי תיאור בלי השבתה, והעריכות הבאות כבר עוברות סקירה, כמו קוד רגיל.
ספקות טכניים: הרשאות, סודות, חזרה משינויים
ספקות בפרויקטי תשתית הם בדרך כלל אותם ספקות: היכן נמצאים המפתחות, למי יש גישה לסביבת הייצור, מה יקרה אם שינוי ישבור את הקונפיגורציה. להלן תשובות קצרות לכל סעיף: איך זה בנוי ביישומים שלנו על Hetzner Cloud ולמה כך ולא אחרת.
היכן נשמרים סודות ומפתחות גישה?
במאגר סודות נפרד, ולא ב-git ולא בקובץ המצב של Terraform. היישום קורא אותם בזמן הריצה, לכן במאגר הקוד וביומני הבנייה נשארות רק הפניות לרשומה. מפתחות מוקצים לחשבונות שירות עם תוקף מוגבל, והסבב מתבצע לפי לוח זמנים.
כיצד מופרדים תפקידים והרשאות?
לכל תפקיד — סט ההרשאות המינימלי הנדרש: מהנדס מיישם תוכנית בסביבת בדיקות, וסביבת הייצור משתנה רק דרך הצינור לאחר אישור. אין הרשאות ידניות קבועות בפרודקשן: הן ניתנות לזמן מוגבל ונרשמות ביומן.
מה קורה כששינוי נכשל?
התשתית מתוארת כקוד, לכן חזרה לאחור היא חזרה לגרסה הקודמת ויישום חוזר. המצב מנוהל בגרסאות, השינויים אידמפוטנטיים, כך שהחזרה אורכת דקות במקום שעות של תיקון ידני.
איך מתבצעת ביקורת פעולות?
כל שינוי עובר דרך בקשת מיזוג עם סקירה מחייבת, לכן בהיסטוריה רואים מי, מתי ולמה ערך את הקונפיגורציה. יומן הפעולות של החשבונות נשמר בנפרד מסביבת העבודה.
נדבר על המשימה: נבחן את הסביבה שלכם ונחזור עם תוכנית
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם מילים כלליות, אנחנו צריכים גישה לעובדות על הסביבה שלכם ב-Hetzner Cloud. להלן הנתונים שאנחנו מבקשים בהתחלה; חלק מהם אפשר לאסוף прямо בשיחת וידאו, אם אין תיעוד.
- תרשים תשתית: אילו שירותים פועלים, היכן הם מתארחים, אילו תלויות חיצוניות ומה קריטי לזמינות.
- איך משחררים שינויים כעת: היכן נמצאים הקוד והקונפיגורציות, מי ובאיזו פקודה מבצע שחרור, כמה זמן אורכת חזרה לגרסה הקודמת.
- הרשאות לבדיקה: טוקנים עם הרשאת קריאה בלבד לענן, גישה למאגר הקוד, למערכות ניטור מצב השירותים וליומנים.
- מגבלות: דרישות אבטחה, נהלים ענפיים, חלונות שבהם אסור לבצע עבודות, ושירותים שאסור לעצור.
- ציפיות מהיקף: יישום מאפס, הרחבת האוטומציה הקיימת של התשתית או תמיכה בתשתית לאחר עלייה.
- תקלות שכבר קרו: מה נשבר, איך שוחזר, אילו פעולות ידניות מתבצעות באופן קבוע ועל ידי מי.
בתגובה אתם מקבלים מפת סביבה עם צווארי בקבוק, תוכנית מדורגת, הרכב העבודות וגבול אחריות: מה אנחנו סוגרים ומה נשאר בצד שלכם. תארו את המשימה — נחזור עם הערכה ותוכנית.