הפרידו בין בדיקות הבריאות של ה-VPN לבדיקות הבריאות של האפליקציה
תהליך מנהרה שרץ, מסלול מוגן, DNS ויעד היעד יכולים להיכשל בנפרד. כל בדיקה תזכיר את השכבה שלה ואת הפעולה שהיא מפעילה.
תהליך המנהרה שלכם יכול לרוץ בזמן שהחיבור המוגן אינו שמיש, ועמוד אינטרנט שנכשל אינו הוכחה שהמנהרה נשברה. כשבדיקה אחת מייצגת את כולן, מדיניות הפעלה מחדש מפעילה מחדש את הרכיב הלא נכון וקוראת לזה אוטומציה. כל בדיקה למטה מציינת את השכבה שהיא צופה בה, את הפעולה שהכשל שלה מפעיל, ואת ההוכחה שהפעולה עבדה. הצעד האחרון הופך את כל המערך לעמוד שמישהו יכול לעקוב אחריו בשלוש לפנות בוקר.
שלב 1: תנו שם לשכבה שכל בדיקה צופה בה
שאלו מה כל בדיקה באמת יכולה לראות לפני שכותבים אחת מהן. חיים מוכיחים שהדמון פועל, לחיצת יד או רשימת עמיתים מוכיחה שהקשר קיים, בקשה מנותבת מוכיחה מסירה, וחיפוש מוכיח פענוח. הן נכשלות בדיוק בסדר הזה, ואף אחת מהן לא מרמזת על הבאה. בדיקת תהליך ירוקה לצד מנהרה מתה היא המקרה הרגיל, לא סתירה.
כתבו את ארבע הבדיקות בסדר הזה, עם הפקודה המדויקת והפלט הצפוי לכל אחת. בדיקה שאינכם יכולים לנסח את הפלט הצפוי שלה תיקרא אחרת על ידי כל מפעיל שיראה את ההתראה. שימו את אותה רשימה בטקסט ההתראה, לא רק במדריך, כדי שהאדם שמוער בלילה יפגוש את השכבה לפני התסמין. שמרו כל פקודה מוכנה להעתקה במארח שמריץ אותה.
לאחר מכן הוסיפו את בדיקת האפליקציה כפריט חמישי, נפרד. עמוד ששירות החשבונות שלו למטה אינו מצדיק הפעלה מחדש של המנהרה.
שלב 2: קשרו כל כשל לפעולה אחת
לכל בדיקה, החליטו מה מופעל מחדש, מה נשאר חסום ומה מזעיק אדם. כשל בשכבת המנהרה יכול להצדיק הפעלה מחדש של המנהרה; כשל בפותר מצביע על שילוב ה-DNS בלקוח; כשל בשכבת האפליקציה כמעט ולא אמור לגעת במנהרה.
אמרו מה כשל אסור לו לעשות, כי ברירות המחדל המסוכנות הן המתירניות. מצב לא בריא אסור לו להפוך אי פעם להרשאה לתעבורת אפליקציה ישירה, מפני שמסלול חלופי שעוקף את המנהרה בשקט מסיר את הסיבה לקיומה. צמצמו גם את הפעולות: הפעלה מחדש של רכיב משותף כי יעד אחד איטי הופכת בעיה מקומית לבעיה של כל הצי. היא גם משמידה את ההוכחה שהייתם צריכים כדי למצוא את הסיבה.
שלב 3: שמרו על הבדיקות בלתי מזיקות וזולות
השתמשו בבקשות קטנות לקריאה בלבד: משאב סטטי, נקודת קצה של בריאות שמדווחת על התלות של עצמה, או חיבור TCP לפורט שאתם שולטים בו. הימנעו מאישורי גישה, מגלישה פרטית ומכל דבר שמשנה מצב בכל מרווח, כי בדיקה שכותבת היא מבחן עומס לפי לוח זמנים.
תעדו את היעד, את ציפיית המסלול ואת פסק הזמן לכל בדיקה. ציפיית המסלול היא השדה שאנשים משמיטים, והיא מה שמפריד בין כשל מנהרה לטעות ניתוב כשאתם קוראים את ההתראה מאוחר יותר. גזרו את המרווח ואת סף הכשל מזמן ההתאוששות שאתם מבטיחים, ושמרו על פסק זמן קצר מהמרווח. בדיקה שעדיין רצה כשהבאה מתחילה מדווחת על כשל אחד פעמיים ונראית כמו הבהוב.
שלב 4: שברו כל שכבה וראו שהבדיקה הנכונה הופכת לאדומה
עצרו את תהליך המנהרה ואשרו שבדיקת התהליך נכשלת בזמן ש-DNS אולי עדיין עונה מהמטמון. שנו מסלול ואשרו שהבקשה המנותבת נכשלת בזמן שהתהליך ולחיצת היד נשארים בריאים. שברו רק את ה-DNS ואשרו שבדיקת האפליקציה מדווחת על פענוח ולא על שגיאת מנהרה. אם שתי בדיקות תמיד זזות יחד, יש לכם פחות בדיקות ממה שאתם חושבים.
בדקו את כיוון ההתאוששות באותה משמעת. אחרי שתשחזרו את השכבה, הבדיקה אמורה להתנקות בלי הפעלה מחדש ידנית, והפעולה שהופעלה לא אמורה להשאיר שום עקיפה מאחור. צפו במחזור שלם לפני שתבטחו במצב הירוק, כי בדיקה שמתנקה רק ביד מסתירה מסלול התאוששות שבור.
שלב 5: הניחו את המדריך במקום שאליו מצביעה ההתראה
עמוד אחד עם חמש שורות נושא את כל העיצוב: שכבה, פקודה, תוצאה צפויה, פעולה בכשל, אחראי. הוסיפו שורה לכל בדיקה על מה היא בכוונה לא בודקת. השורה הזו היא מה שמונע מהאדם הבא להוסיף בדיקה שישית שמודדת הכול ולא מבדילה דבר. קשרו את העמוד מטקסט ההתראה, אחרת איש לא יפתח אותו בזמן שהתקרית פעילה.
בפריסות מכולות, תנאי תלות מעצב את האתחול ולא שום דבר אחר. סדר האתחול ותנאי הבריאות של Compose מתעד כיצד מוכנות קובעת את הסדר שבו שירותים מתחילים; שום דבר מזה לא אוכף מדיניות יציאה לאחר מכן, ושום דבר מזה לא נכשל סגור כשהמנהרה נופלת. אכיפה מתמשכת זקוקה למדיניות משלה ולבדיקה משלה, כתובות באותו עמוד.
המדריך מוכן כשהשכבה הנכונה מתאוששת בלי שמישהו יקרא אתר לא זמין כמנהרה שבורה. זה בודק את המסמך, לא את המנהרה.