מאת: רוברט ברון | ארכיטקט SRE בקבוצת ה-CIO הגלובלית IBM
כפי שהצגתי במאמרי הקודם, ישנם מספר שלבים בטיפול בתקלות בסביבת ה-IT שלנו וככל שנהייה יעילים יותר בכל אחד מהשלבים, נוכל לפתור תקלות בצורה מהירה ויסודית יותר.
במאמר זה אתרכז בשלבים הראשונים – זיהוי התקלה וניתוח המקור.
אחת הבעיות המרכזיות בזיהוי תקלות, במיוחד בסביבות ה-IT המודרניות שהן יותר ויותר היברידיות – ז"א שילוב של סביבות ענן ציבורי, ענן פרטי ו- data centersמסורתיים שמכילים את כל סוגי השרתים מהמיינפריים ועד ה-IoT – היא שאנחנו סובלים מעודף נתונים.
בכל ארגון בו ביקרתי קיים מערך של פתרונות שו"ב מגוונים, שכל מערכת אוספת כמה שיותר פריטי מידע על השירותים עליהם היא אמונה.
עכשיו שאספנו את כל המידע הזה, שרובו "תפל", קשה להוציא ממנו את העיקר.
יש לי שרת שבו המעבד קפץ מניצולת של 75% ל-90%. האם עליי לדאוג?
יש תור של Message Queue שמעביר 50% יותר פריטים היום מאשר אתמול. הם זה סימן לבעיה?
מערכת הגיבוי רצה ב-2 לפנות בוקר במקום ב-1:30. האם זה מסכן את המערכות שלי?
ועוד ועוד...
מערכות Monitoring מאוד טובות באיסוף מידע אבל צריך גם דרך לעשות סדר בבלגן.
הפתרון: אותות הזהב The Golden Signals
כדי לעשות סדר בבלגן נתייחס לכל רכיב בתור שירות הנותן מענה לצרכן – מעבד נותן זמן עיבוד לתהליכים, מאגר נתונים נותן נתונים לצרכן המריץ שליפות, מיקרו-שירות נותן מענה על בסיס ה-API שלו וכו'. כך נוכל להגדיר סדרה סטנדרטית של מדידות או "אותות" שנאסוף מכל רכיב.
בכדי לדעת כיצד הרכיב מתפקד, נגדיר ארבע סוגים של מדידות שנמדוד לאורך פרק זמן קצר. במילים אחרות, אם אנחנו מודדים אות מסוג "כמות בקשות" אז אנחנו נמדוד "כמה בקשות התקבלו ב-30 שניות האחרונות" ולא "כמה בקשות התקבלו בסה"כ או מאז תחילת השבוע".
זמן המתנה – Latency משך הזמן שלוקח לפעולה כלשהי להתבצע. פעולה זו יכולה להיות טכנית (כמה זמן לוקח לכתוב לדיסק או לבצע שליפה) או עסקית (כמה זמן לוקח למשתמש לבצע את הפעולה שהוא או היא מבקשים לבצע).
תעבורה – Traffic כמה הפעולות המתבצעות מול השירות שאותו אנחנו מודדים. כאן לא משנה אם משתמש אחד מבצע אלפי פעולות או אלפי משתמשים מבצעים פעולה אחת.
שגיאות – Errors שגיאות הן כמות הפניות אשר אינן מצליחות לתת את המענה הנדרש. שגיאה יכולה להיות "HTTP 404 – דף לא נמצא" או "שליפת ה-SQL לא בנויה בצורה תקינה" או כל דבר אחר המציין כשלון במתן מענה תקין. אפשר להגדיר שמענה הוא שגוי אפילו אם טכנית הוא הצליח – למשל, בקשה שלוקחת יותר מדי זמן יכולה להיות מוגדרת כשגוייה, לא משנה שהיא מתבצעת בסופו של דבר.
רוויה – Saturation המדד הכי מורכב הינו "כמה תור הבקשות שלי מלא". במקרה של ציוד חומרה אז יחסית פשוט להגדיר את הרוויה ורואים אותו בקו תקשורת עמוס או דיסק שמתקרב לקצב המקסימאלי שלו. במקרה של שירותים מורכבים יותר, קשה להגדיר את סף הרוויה בצורה מוחלטת, אבל אפשר לבצע הערכות או לוותר על סוג האות הזה.
נהוג לחלק את האותות ל-2 קבוצות:
זמן תגובה ושגיאות הן בעיות אשר הצרכנים שלנו מרגישים – אם זמן התגובה איטי מדי או יש שגיאות רבות מדי, אז סביר להניח שתלונות הולכות לבוא בקרוב. תעבורה ורוויה אינן בעצמן בעיות, אבל הן סימן מעיד למקור של בעיות.
בטבלה הבאה ישנן מספר דוגמאות של ארבעת המדידות עבור ארבעה סוגים של רכיבים בעולם ה-IT.
הרבה פעמים נוכל לראות קשר בין שגיאות ואיטיות בשירותים מסוימים לתעבורה ורוויה בשירותים בהם הם תלויים. כך נוכל לדעת באיזה שירות צריך להתרכז בכדי לפתור את הבעיה.
תרשים המציג תלויות בין רכיבים ואת "אות הזהב" עליו הן מתריעות
בתרשים מעל אנחנו רואים טופולוגיה של מערכת– ולא משנה אם מדובר במערכת המורכבת מסדרה של micro-services, מערכת distributed, רשת תקשורת, או חומרה מיוחדת – כל מה מעניין אותנו זה הקשר בין הרכיבים ו-"אותות הזהב" עליו הם מתלוננים.
התקלה נפתחת מול רכיב A, צרכנים מתלוננים שזמן התגובה איטי מידי (שוב, לא משנה אם מדובר בזמן תגובה בגישה לאתר באינטרנט, הזמן שלוקח להוריד קובץ, הזמן שלוקח לעדכן רשומה במאגר נתונים או כל דבר אחר – ההתייחסות זהה בכל מקרה).
על פי עקרון אותות הזהב, מיד נבין שכנראה אין באמת "תקלה" ברכיבים A, B, ו-C.
שוב, על פי אותו עיקרון נבין שרכיב D קרוב לגבול הטכני שלו – אולי נוכל לפתור את הבעיה ע"י הקצאת משאבים לפי סוג הרכיב (הוספת כוח עיבוד, שימוש באחסון מהיר יותר, וכו')
אבל מרבית תשומת הלב שלנו תיפול דווקא על רכיב E – שהוא זה שמעמיס על כל שאר הרכיבים. אולי נוכל לצמצם שימוש בו? אולי אפילו לכבות אותו עד יעבור זעם והצרכנים של רכיב A יפסיקו להתלונן?
תהיה התגובה שלנו אשר תהיה, השימוש ב-"אותות הזהב" עזר לנו להתמקד ברכיבים שגורמו לבעיה ולסנן את הרעש מכלל הרכיבים שסובלים ממנה.
שימוש מתקדם ב-"אותות הזהב" ושילוב בינה מלאכותית:
כאשר בוחנים את האותות בצורה משולבת, ניתן להסיק מסקנות באופן פשוט ומהיר:
נניח וזמן ההמתנה שלנו עלה ב-10% במהלך השעה האחרונה והתעבורה עלתה ב-100%. במקרה כזה, כנראה שהאיטיות נגרמת מעומס לגיטימי על המערכת ואין צורך להתרגש. אבל אם הזמן ההמתנה עולה ב-100% והתעבורה רק עלתה ב-10% אז כנראה שיש לנו בעיה בהתמודדות עם העומס שנוצר.
כאשר הרוויה של שירות הולך וגדל אבל זמן התגובה לא משתנה ואין הצטברות של שגיאות, אז אנחנו במצב שבו בעיה הולכת ומתקרבת, אבל טרם משפיעה על הלקוחות שלנו. למשל, כאשר דיסק הולך ומתמלא, על אחד נשאר "קצת מקום" הצרכן לא ירגיש בעיה בכלל. זו ההזדמנות שלנו לפתור תקלה לפני שהיא תשפיע.
נניח ופתאום אנחנו רואים קפיצה בכמות השגיאות שמגיעות משירות מסוים. האם עלינו להילחץ? תלוי – אם כמות התעבורה גם עולה ובפרופורציה לכמות השגיאות אז בסופו של דבר צרכן הקצה מקבל את אותה חוויה ואותה כמות שגיאות באופן אישי.
אפשר למצוא פתרונות רבים המשלבות את אותות הזהב וניתן גם לייצר פתרונות Do It Yourself. למשל, מסך ה- Grafana הבא מייצג את אותות הזהב של רכיב ומציג את כל ארבעת האותות במקביל, דבר שעוזר להתמקד בפתרון הבעיה.
אבל גם כאשר משתמשים באותות הזהב כדי להתמקד, ייתכן ועדיין יהיו לנו יותר מדי נתונים, כאן נכנסות מערכות בינה מלאכותית אשר מזהות חריגות באותות הזהב ואת הקשרים בין רכיבים שונים.
המסך הבא מגיע ממערכת Instana והוא מציג את אותות הזהב של micro-service. במקום מסך ג'נרי עבור אותות הזהב, למערכות מסחריות בד"כ ישנן גם מסכים ייעודיים על פי סוג הרכיב, דבר המקל עוד יותר על הניתוח של המערכות.
כמובן שלא מספיק רק לדעת מה מקור הבעיה, אלה שצריך לדעת כיצד לפתור אותה כמה שיותר מהר. על זאת (ועוד) ארחיב במאמר הבא.
סיכום:
כתבה זו הציגה רק את קצה הקרחון של האפשרויות הנובעות משימוש באותות הזהב בפתרון תקלות IT בסביבת Production.
צירוף הלקחים מהמאמר הקודם הדן בשילוב מערכות בינה מלאכותית לומדות רק מכפילות את התועלות – צמצום כמות הנתונים שבני האדם צריכים לעקוב אחריהם ומציאת חריגות באופן מהיר ויעיל.
במאמרים עתידיים ארחיב על כיצד ניתן להגיע לפתרון מהיר ויעיל של תקלות שזוהו ע"י אותות הזהב.
בינתיים אשמח להרחיב עמכם את השיחה. ניתן ליצור איתי דרך האתרים הבאים:
בברכה,
רוברט ברון, ארכיטקט SRE בקבוצת ה-CIO הגלובלית IBM
