אמזון מוסיפה בדיקות לערכי ההגדרות בענן: מה הן עוצרות, ומה עדיין צריך לבדוק בקוד

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

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

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

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

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

מספר תקין אינו בהכרח מספר מתאים

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

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

כתובת חשבון עוברת בדיקת מבנה בלבד

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

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

כתובת רשת אינה טווח ואינה חיבור פעיל

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

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

גם כתובת דואר ושם שרת מוגבלים בכללים

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

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

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

מסמכים מובנים מחייבים מסלול מתקדם

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

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

כתובת קישור תקינה אינה רשימת אתרים מורשים

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

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

גם אחרי האימות היישום מקבל מחרוזת

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

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

העלות נקבעת גם לפי מספר הערכים והקריאות

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

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

מתחילים בקבוצה קטנה ומודדים מה נדחה

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

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

מצאתם טעות או תוכן לא ראוי? דווחו לנו >>