מניעה ותיקון של סחיפה תשתיתית ב-Terraform עבור Azure

By Mirko Peters · 2026-10-28

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

Automatically translated with AI from the original post. Read the English original

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

עיקרי הדברים

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

מהי סחיפה תשתיתית, ומדוע היא מתרחשת?

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

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

הגורם האנושי ולחץ התפעולי

סחיפה כמעט אף פעם אינה זדונית; היא כמעט תמיד נולדת מדחיפות תפעולית. כאשר סביבות ייצור קורסות, האינסטינקט האנושי מורה למהנדסים לעצור את הנזק מיד, באמצעות הכלים המהירים ביותר. הקצאה בלחיצות בפורטל של Azure מהירה, מוחשית ומיידית. עם זאת, בכל פעם שמהנדס משתמש בפורטל כדי לתקן בעיה בלי לתעד אותה בקוד, הוא יוצר חוב טכני שיצטרך להיפרע מאוחר יותר בריבית.

כיצד ה-state של Terraform מזהה אי-התאמות

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

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

הסכנה שבאזהרות שמתעלמים מהן

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

שיטות עבודה מומלצות לזיהוי סטיות ולמניעתן

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

• אכיפת גישה לקריאה בלבד: הסירו הרשאות כתיבה בסביבת ההפקה ממשתמשים אנושיים. כל שינויי התשתית צריכים לעבור דרך צינורות ה-CI/CD שלכם ודרך סקירות של בקשות משיכה (pull request).
• תזמון הרצות plan אוטומטיות: הגדירו צינורות אינטגרציה מתמשכת שמריצים באופן קבוע את הפקודה 'terraform plan' בלי להחיל אותה. בדקו את הפלט לאיתור שינויים בלתי צפויים.
• פיצול קבצי מצב מונוליטיים: פצלו סביבות גדולות לרכיבים מודולריים וקטנים יותר. קבצי מצב קטנים יותר מקלים על בידוד, בדיקה ותיקון של סטיות.
• הטמעת נעילת מצב מרוחקת: ודאו שהצוות משתמש ב-backends מרוחקים מאובטחים עם נעילת מצב, כדי למנוע הרצות במקביל שיפגעו ברשומות המצב.

כיצד לתקן סטיות כשהן מתגלות

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

האפשרות הראשונה היא לתת ל-Terraform לדרוס את הסביבה החיה. על ידי הרצת 'terraform apply' הרגילה, אתם מאלצים את Azure לחזור למצב המתואר בקוד. זו הדרך הנכונה כאשר הסטייה נגרמה משינוי ידני לא מורשה או מהגדרת ניפוי שגיאות זמנית שאמורה כבר לא להתקיים.

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

סיכום

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

שאלות נפוצות

מה גורם לסטיית תשתית ב-Terraform?

סטייה נגרמת משינויים שנעשים ישירות במשאבי הענן, דרך פורטלים, פקודות CLI או סקריפטים שעוקפים את צינור Terraform.

כיצד Terraform מזהה סטיית הגדרות במהלך הרצת plan?

Terraform משווה את קובץ המצב השמור שלו מול משאבי הענן החיים בפועל, דרך ממשקי ה-API של הספקים, ומול קובצי ההגדרות המקומיים שלכם.

מה קורה אם מישהו משנה ידנית משאב Azure שמנוהל על ידי Terraform?

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

האם עליי לעדכן את קוד Terraform או לבטל את השינוי בפורטל Azure?

אם השינוי הידני היה תיקון חירום (hotfix) שכעת נדרש ליציבות המערכת, עדכנו את תצורת Terraform שלכם. אם מדובר בשינוי לא מורשה או בשינוי שנעשה בטעות, הניחו ל-Terraform להחזיר את המצב לקדמותו.