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

תרגמו את הדרישה, לא את שם המוצר

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

ההבחנה הזו היא כל הסיבה לכך שדרישת קו יכולה להיות לגיטימית ובכל זאת לא להיות דרישת VPN. שער עם ממשק טורי בלבד באמת זקוק למסירה טורית, וזו מגבלת חומרה ולא מגבלת פרוטוקול. החליפו את המכשיר והמגבלה נעלמת. כתבו כל דרישה בצורה «השער זקוק ל-X מפני ש-Y», ודחו כל שורה שאי אפשר להשלים.

תנו שם למסירה לפני שאתם נותנים שם למהירות

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

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

ip -br link show
ethtool eth0 | head -20
sudo lshw -class network -short

אשרו את אספקת ה-IP, לא רק את הכתובת

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

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

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

ip -br addr
ip route get 198.51.100.10
traceroute -n 198.51.100.10

מדדו קיבולת לפי עומס העבודה, בשני הכיוונים

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

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

קביעו את ההתחייבויות התפעוליות

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

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

אמתו את הקו מול התנאים הכתובים

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

iperf3 -c speed.example.net -t 30 -P 4
mtr -n --report -c 50 198.51.100.10
curl -sS -o /dev/null -w '%{time_connect} %{time_starttransfer}\n' https://speed.example.net/

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

לבסוף, קראו שוב את ארבעת השערים מול מה שנמסר. למסירה, לאספקת ה-IP, לקיבולת ולתנאי התמיכה יש שורה ברשומה, ולצד כל שורה שם.

מאמרים קשורים