עושים סדר בעולם הניטור

מתי משתמשים ב-Grafana ולמה כדאי להשקיע בניטור תשתיתי? בואו להכיר את כל הרכיבים של תחום הניטור בפיתוח מודרני

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

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

ניתן לחלק את תחום הניטור כיום לחמישה תת-תחומים עיקריים:

ניטור תשתיתי – מדובר בניטור הקלאסי של עולם ה-IT שבודק למעשה את המאפיינים הפיזיים של התשתית כמו שרתים, דיסקים, ציוד תקשורת ועד למיזוג אוויר וחשמל. המעקב יכול להתחיל בטמפרטורה של המעבד בשרת, דרך מהירות המאווררים, ועד למתח המגיע לציוד התקשורת. עם השנים והשימוש בשירותי ענן הצורך בניטור הפיזי הלך והתמעט, כיוון שחברות הענן דואגות לניטור הזה באופן קבוע, ומבצעות גם את הפעולות הנדרשות במקרה של חריגה. במידה ואתם מנהלים שרתים משלכם הצורך בניטור התשתית הוא כמובן הכרחי. כלים פופולריים בתחום הזה הם SolarWindsNagios או שירותי ענן כמו Datadog. הכלים הללו דורשים היכרות מעמיקה עם המאפיינים של התשתית, כמו לדוגמא טמפרטורות פעילות מומלצות, בשביל ליצור התראות (Alerts) מדויקות.

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

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

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

אחד היתרונות של Grafana, פרויקט קוד פתוח פופולרי, היא סביבה עשירה של תוספים (Plugins) שיכולים לסייע לכם לבנות את הפתרון הגרפי הרצוי במהירות. החל ממפות עולמיות, דרך בדיקת מהירות הגישה לאפליקציה שלכם מכל מקום בעולם, ועד תוספים שמתממשקים לשירותי ענן שונים כמו Azure, או בסיסי נתונים כמו MySql ו-PostgreSQL וכמובן בתוסף שמציג שעון או נתונים מלוח השנה של גוגל, אם אתם רוצים להציג על לוחות המחוונים שלכם תאריכים חשובים.

ניתוח יומני מעקב (Log Files) – כל שירות מייצר היום כמות עצומה של נתונים לצורך מעקב היסטורי, והיכולת לנתח אותם היא שימושית כדי לבדוק מגמות לאורך זמן או לנתח תקלות שמתרחשות בתכיפות נמוכה יותר. במשך שנים Splunk הייתה השליטה הבלתי מעורערת, אבל ELK הפלטפורמה מבוססת קוד פתוח של חברת Elastic כבשה את התחום בסערה. למרות שהן לא תמיד מציעות את אותן היכולות, Splunk היא כלי יקר, לעומת המחיר העגול של ELK שעומד על אפס בדיוק. למרות היכולת להשתמש בכלים בחינם, הגדרה והטמעה מדויקת שלהם לצרכים שלכם, דורשת כבר יותר מומחיות וניסיון, וייתכן שכאן שווה להשקיע במומחים שיסייעו בהתאמה לדרישות שלכם. ראויות לציון בתחום GraylogDatadog וגם logz.io הישראלית שמתחברת לסביבה של ELK.

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

מגמות מעניינות בעולם ה DevOps

מאת: רועי בריהנד

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

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

Kubernetes הופכת לפלטפורמה משמעותית – למרות שהיא כבר השליטה הבלתי מעורערת בתחום ניהול הקונטיינרים, הרי בשנה החולפת רשמה Kubernetes מספר ציוני דרך חשובים. התמיכה הרשמית בפרויקט מצד אמזון, אורקל, מיקרוסופט ו-VMWARE בפרויקט הקוד הפתוח, מהווה הבעת אמון בפלטפורמה ומעודדת משקיעים להשקיע בסטרטאפים חדשים המפתחים כלים המבוססים על הפרויקט. בין היתר כדאי להסתכל על חברות כמו Hasura שמפתחת גרסת Kubernetes המיועדות למפתחים, Upbound שמפתחים מוצר לניהול סביבות מורכבות של עננים ושרתים, Heptio שמציעה תמיכה בהטמעת Kubernetes בארגונים גדולים, וחברות אחרות כמו CoreOS ו-Deis שכבר נמכרו לחברות הגדולות.

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

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

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

התמחות ב-Machine Learning  – למידת המכונה (ML) או בינה מלאכותית (AI) הפכו לכלי חובה בכל שירות מקוון היום, בין אם מדובר באפליקציית תמונות פשוטה או במערכת מורכבת לניהול שרשרת אספקה ארגונית.

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

שילוב של AI/ML ניתן למצוא גם בכלים המיועדים לעולם ה-DevOps. מערכות של ניטור וניתוח מידע משלבות כלים הלומדים את ההתנהגויות של המערכות באופן שוטף. כך הן מסוגלות להתריע בצורה חכמה על תקלות אפשרויות מבעוד מועד. עדיין קשה לומר שהמערכות הללו מחליפות את העיניים האנושיות אבל אנחנו רואים יותר ויותר כלים מתקדמים מסטרטאפים מעניינים בתחום.

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

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

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

DevOps מוכוון אבטחה – על אבטחה כולם אמורים לחשוב כל הזמן, אבל בשנה החולפת התחדד הצורך להפוך את האבטחה לרכיב בלתי נפרד גם ברמת ה-DevOps. בסוף 2017 נחשף כי האקרים פרצו לחברת Uber וגנבו פרטים של 57 מיליון משתמשים ו-600 אלף נהגים. ההאקרים גילו שמפתחים ב-Uber פרסמו קוד ב-Github שכולל שם משתמש וסיסמה לרשת הפנימית של Uber. הפריצה הזאת הצטרפה לפריצות אחרות של שירותים גדולים, שבהם הגדרה לא נכונה של משאבי אחסון בשירותי הענן של אמזון, חשפה מידע פרטי של מיליוני לקוחות.

דוגמא נוספת לחשיבות של תכנון אבטחה נכון גם ברמת ה-DevOps פגשנו לאחרונה אצל לקוח אשר סבל ממתקפת מניעת שירות (DDOS) של מספר שעות. מכיוון שהשירות המרכזי נפל, המערכת העבירה את השירות לאתר המשני (DR) אך האתר המשני תוכנן להתמודד עם סדרי הגודל הרגילים של השירות. כך כאשר אתר ה-DR נתקל במתקפת מניעת השירות שכלל תנועה של פי 100 מהרגיל, גם הוא קרס.

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

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

מה זה DevOps?

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

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

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

כל ההתחלות קשות

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

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

בתחילת המילניום, הידע והניסיון מתחום ה-IT הספיקו כדי להתמודד עם שירותי המחשוב החדשים. אבל בעשור האחרון, כאשר תשתית המחשוב עברה שינוי מהותי בזכות שירותי הענן, הפך תחום ה-DevOps לתחום שדורש מומחיות, התמחות וניסיון רב. ניצול נכון של שירותים הוא מדד בלתי נפרד מהצלחה של חברה. אחת הדוגמאות לכך היא WhatsApp שכאשר נרכשה על ידי פייסבוק ב-2014 מנתה רק 18 עובדים, אבל הייתה בשימוש אצל לא פחות מ-1.8 מיליארד משתמשים ברחבי העולם. היכולת לשלוט על תהליך הפיתוח וההפצה של האפליקציה למגוון מכשירים, בכל רחבי העולם, הוא דוגמא ליכולות הטכנולוגיות העומדות היום לרשות כל ארגון, ולא פחות מזה, ליכולות של אנשי ה-DevOps שהיו בחברה.

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

DevOps הדור הבא

עם ההשתכללות של כלי הפיתוח וההפצה, הפכו תהליכי ה-DevOps למבוססים על Continuous Integration/Continuous Delivery/Continuous Deployment – אינטגרציה, הפצה והטמעה מתמשכות או בקיצור CI/CD. השלב של אינטגרציה משתמשת כולל שילוב של קוד מצוותי פיתוח שונים אפילו מספר פעמים ביום, כדי לבחון שינויים באופן כמעט מיידי. כאשר השלבים הבאים של הפצה והטמעה כוללים בדיקות אוטומטיות והפצה של השינויים למשתמשים. כך צוותי הפיתוח יכולים לקבל בחזרה פידבק מהמשתמשים מבלי להמתין זמן ממושך.

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

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

כמה העסק שלך מפסיד בדקה?

מאת: אבי שליסמן

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

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

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

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

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

האמת נמצאת בנתונים

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

בחלק מהמסכים בסטרטאפים קטנים ניתן לפגוש גם נתון מעניין המוצג בזמן אמת – הכנסות מלקוחות משלמים. למרות זאת מעולם לא נתקלתי במסך שמציג נתוני הפסד במידה והשירות אינו זמין. את הנתון הזה קל יחסית לכמת – הכנסות חודשיות חלקי מספר הדקות בחודש (43,800 לעצלנים) יתנו לכם נתון מהיר שתוכלו להשתמש בו במידה שיש הפרעה בשירות. כאשר מציגים לצוותי הפיתוח וה-DevOps נתון כספי ברור צבוע באדום, עם סימן מינוס לידו שגדל בכל דקה, העובדים מפנימים בצורה ברורה את העלות האמיתית של זמן התקלה. זאת עוד לפני שנלקחה בחשבון העלות של זמן העבודה שמוקצית כרגע לתיקון תקלה במקום עבודה על משימות מתוכננות.

 

פיתוח מוכוון זמינות

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

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

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

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

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