About moadmin

This author has not yet filled in any details.
So far moadmin has created 62 blog entries.

אופרציה מוצלחת 24/7? זה לא בשמיים

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

השקעה ב-NOC כאסטרטגיה עסקית מכרעת

כיום, עדיין יש אחיזה לתפיסה הרואה בשירותי NOC אנושיים תופעה מיושנת. רבים עדיין סבורים עדיין כי אוטומציית NOC מהווה תחליף הולם לאנשי NOC העומדים לשירות הארגון באופן שוטף, אך זו כשלעצמה תפיסה מיושנת.
אימוץ גישה אסטרטגית ל-NOC, כמתחייב מטיב פעילותן של חברות SaaS ומתנאי השוק, מצריך כצעד ראשון, השקעה משמעותית במשאב האנושי. הגדרת תפקידם של מהנדסי ה-NOC המשרתים את הארגון כאסטרטגי וכצופה פני עתיד יאפשר לאתר בעיות פוטנציאליות מבעוד מועד, באופן יעיל בהרבה. כך ה- NOC יהפוך לכלי פרואקטיבי חשוב, המבטיח שיפור משמעותי באופרציה.
מהנדסי NOC הם גם אנשי הצוות האידאליים לתפעול מערך ה-NOC 24/7, לאור היכרותם המעמיקה עם בעיות אופרציה פוטנציאליות ויכולתם לאבחן בעיות כאלה בשלב מקדמי. יתר על כן, מומחיותם והיכרותם עם המערכת מאפשרות למהנדסי ה-NOC להגיב במהירות לבעיות שצצות ברמה היישומית ולפתור אותן. הדבר מפחית את העומס המוטל על מחלקות המו"פ וה-IT ומאפשר להן להתמקד בפעילות פיתוח ברמה האסטרטגית.
בד בבד, לצד שימוש בשירותיהם של מהנדסי ה-NOC, יש לשכלל את תהליכי הניטור עצמם ואת הידע שבבסיסם. כפי שיפורט להלן, מערך NOC מוצלח, המותאם לצורכיהן העדכניים של חברות SaaS, כולל שלושה מרכיבים מרכזיים: שימוש בלוח בקרה מרכזי וניהול ממורכז של Runbook/Playbook שמתעדכן באופן שוטף; תפעול NOC חכם 24/7/365; והישענות על מערך ניטור אנושי בזמן אמת.
רק שילוב בין שלושת המרכיבים הללו יאפשר ניצול מיטבי של הכלים, הכישורים והתהליכים העומדים לרשות הארגון בתחום הניטור, ויבטיח אופרציה יעילה לאורך זמן.

Runbook/Playbook מתעדכן שמחובר ללוח בקרה מרכזי

מערך NOC מוצלח מתבסס על חיבור בין לוח בקרה מרכזי שדרכו מתבצעת כל פעילות הניטור, לבין Runbook/Playbook ממורכז, שמתעדכן באופן שוטף ומכיל את כל הידע שהצטבר בארגון בתחום הניטור עד אותה נקודת זמן.
באופן זה ניתן לקבל בכל רגע נתון תמונת מצב כוללת ומדויקת באשר לאיכות האופרציה של שירותי החברה ולטפל בצורה יעילה יותר בתקלות קיימות ועתידיות. במילים אחרות, אינטגרציה בין ה- Runbooks השונים הקיימים בארגון וחיבורם ללוח בקרה מרכזי מאפשר זרימה יעילה רציפה של ידע חיוני בתוך הארגון. מי שנהנים מכך הם אנשי ה-NOC בארגון ומשתמשי הקצה כאחד.
תוכנת ה-XiteIT שפיתחנו ב-MoovingON היא מוצר ייחודי שיוצר את החיבור הנדרש בין ה-Runbook הארגוני לבין לוח בקרה מרכזי שאליו מוזרמות כל ההתרעות על תקלות קיימות ופוטנציאליות במערכת. איך זה עובד?
ראשית, לוח הבקרה המרכזי שלנו מקנה לכל אדם מורשה בארגון בכל רגע נתון גישה לסטטוס ביצועי המערכת הכוללים, אשר מוגדרים לפי מדדים ופרמטרים ברורים המותאמים אישית לכל בעל תפקיד. כך ניתן לזהות ביתר קלות את מקורן של תקלות שנוטרו ולפתור אותן באופן יעיל יותר.
שנית, לוח הבקרה המרכזי מחובר ל- Runbook ארגוני פעיל, שמגיב בזמן אמת להתרעות הזורמות ללוח הבקרה המרכזי באמצעות שורה פשוטה, מדויקת וברורה של משימות לביצוע המיועדות לטפל בבעיה המדווחת, בלי קשר לרמת המורכבות של הבעיה. לצד זה, ה- Runbook מתעדכן כל העת, בהתאם לפתרונות חדשים שהותאמו לתקלות שאותרו במערכת.
עדכון ה- Runbook באופן שוטף מאפשר תיעוד ושיתוף של ידע ארגוני חיוני שנצבר בידי אינדיבידואלים בארגון. באופן זה, פוחתת התלות של הארגון בבעלי תפקידים ספציפיים ומתאפשרת העברה יעילה של ידע בתוך הארגון.
הייחודיות של XiteIT נעוצה, בין השאר, במנעד האוטומציה שהיא מציעה. רמת האוטומציה ניתנת להגדרה לפי צורכי הארגון ואופי המערכת: החל מהפעלה אוטומטית של Runbook מתאים, דרך עבודה היברידית, המשלבת בין הפעלה אוטומטית ומעורבות של גורם אנושי, וכלה בשימוש ב-Runbook, המחייב תפעול ע"י גורם אנושי.

NOC חכם 24/7

ביסודו של דבר, על מנת להבטיח פעילות רציפה וחלקה של המערכת, יש לנטר אותה באופן שוטף, 24/7, באמצעות מערך NOC חכם. מערך כזה מנטר לא רק את פעילות הרשת והתשתית, אלא גם את תקינות האופרציה של האפליקציה והשירותים עצמם, ומזהה כל שינוי רלוונטי שעשוי להעיד על תקלה קיימת או פוטנציאלית. כמו כן, NOC חכם יתבצע דרך לוחות בקרה המותאמים באופן ספציפי לצורכי הארגון, ויאפשר לסנן החוצה התרעות כוזבות או לא רלוונטיות.
ניטור איכותי של מערכות SaaS המבקשות לספק שירותים רציפים, יתבצע בארבעה רבדים: ניטור תשתיות; ניטור לוגים ותצוגה גרפית; ניטור השירות (SLA); וניטור האפליקציה. באמצעות כלי הניטור המוטמעים בו, מערך כזה מתעד ומסווג את מכלול הדיווחים על אירועים, תופעות ותקלות שאותרו בשרתים, ברשת או בתפעול האפליקציה עצמה. כך מתקבל ניתוח מקיף וכולל של כל היבטי האופרציה של המערכת, בכל רגע נתון.
הודות לכך, ניתן לקבל החלטות ולספק פתרונות יעילים לתקלות פוטנציאליות באופן פרואקטיבי, בכל אחד מרובדי האופרציה, ולא רק להגיב בדיעבד לתקלות שמתרחשות בזמן אמת. רק באופן זה ניתן להבטיח אופרציה רציפה ומוצלחת של השירות שהחברה מספקת, ולכן הישענות על מערך NOC מתקדם משקפת ראייה עסקית נכונה של סוגיית הניטור.
על מנת למצות את יתרונותיו של מערך NOC חכם יש לשלבו עם חלוקת עבודה מרובדת בקרב אנשי ה-DevOps/Dev. במסגרת חלוקת עבודה כזו, מהנדסי NOC יתמקדו בטיפול בבעיות שמאותרות באמצעות מערך ה-NOC באופרציה השוטפת של המערכת, וכך יוכלו מהנדסי ה-DevOps/Dev המתמחים בפתרון בעיות ברמה יסודית יותר להתמקד בהצגת פתרונות תמיכה במישור זה ובהטמעת תהליכים אסטרטגיים שהארגון מעוניין ליישם.
השילוב בין מערך NOC חכם בעל רבדים שונים לבין חלוקת עבודה מרובדת בקרב צוות התמיכה, מאפשר לארגון לאתר תקלות קיימות ופוטנציאליות בצורה יעילה יותר, לתעדף נכון יותר את הטיפול בהן ולהגיב להן מהר יותר, מבלי לבזבז משאבים חיוניים של מהנדסי פיתוח.
בה בעת, ועל אף שהשימוש במערכות ניטור ייעודיות שמתמחות בכל אחד מרובדי הניטור טומן בחובו יתרון משמעותי, הדבר מאתגר את צוות ה-NOC, כיוון שיש מקורות רבים שצריך לעבוד איתם. לכן רצוי להטמיע לוח בקרה מרכזי שיאפשר לעבוד בצורה מרוכזת ויעילה יותר.

חשיבותו של ניטור אנושי בזמן אמת

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

Monitoring and Automation for Growth and Scale – סיכום מפגש

ניטור סביבת הפרודקשיין הינו תהליך מורכב הבא לתת מענה לצרכים שונים:
(1) לוודא שהשירות זמין עבור לקוחות הקצה
(2) לאפשר גילוי מוקדם ככל האפשר של בעיות
(3) לאפשר מעקב אחר מדדים עסקיים

מניסיון רב השנים ועבודת השטח הדינמית, עלה הצורך בשיתוף ידע לטובת ייעול ואופטימיזציה של תהליכים וכך נולד הרעיון ליזום מפגשים (מיטאפים) לקהילת אנשי ה IT בתחום הניטור והאוטומציה.
למעלה מחמישים משתתפים הגיעו למפגש הראשון שערכנו בתחילת החודש ועמד בסימן:
Monitoring and Automation for Growth and Scale
בהרצאות השונות שהתקיימו, הציגו מומחים מחברות גדולות שיטות עבודה מומלצות ולקחים. שמחנו לארח את:

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

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

דמי בן ארי (Co-founder and CTO at Panorays ) התמקד בנושא החם היום בתעשייה – Kubernetes. דמי דיבר על הניסיון של הצוות הטכני ב Panorays בהטמעת פתרון של Kubernetes שנותן מענה לצרכים העסקיים וכן דיבר על זוויות הניטור הנדרשות בסביבת Kubernetes שבה יש פחות משקל לתשתית אך יש משקל רב בניטור התהליכים והצרכים העסקיים.

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

סיפור לקוח – Sisense

הפתרון של Sisense מנתח את המידע הרגיש ביותר בחברות הגדולות בעולם. לפיכך, היה זה ברור ש-MoovingON תהיה זאת שתשמור על שירות הענן של Sisense.

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

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

ב-Sisense ביצעו תהליך ממושך של בחינת חברות בתחום גם בארץ וגם בעולם. ספקי השירות בחו"ל נפסלו בשלב המוקדם מאוד. בארה"ב ובאירופה,ספקי השירות השונים מציעים שירותים טובים אך ברמת מחיר גבוהה בהרבה לעומת ישראל, והספקים במזרח מציעים שירות בעלות נמוכה יותר אך רמת השירות היא בהתאם. לאחר מכן ביצעו ב-Sisese בחינה של ספקי השירות בארץ ובחרו ב-MoovingON בשל הניסיון המגוון והידע המקצועי הנרחב בשירותי AWS. "מכיוון שהיינו צריכים בעצם לצבור ניסיון תוך כדי ריצה, היה חשוב לנו שותף שנמצא בארץ ונגיש בקלות, ביחד עם הידע והניסיון הממוקד בהקמת מרכז בקרת רשת, ולא בתור שירות נוסף בחלק משירותי IT שהן מציעות", אומר זלדנר. מסתבר כי כאשר רצו לבקר במרכזי הבקרה של חלק מספקיות השירות הן טענו ש"זה בתהליכי הקמה" או ש"ממש עכשיו אנחנו קונים מסכים", כאשר ב-MoovingON יש מרכז בקרה מתקדם שפועל מאז הקמת החברה וניתן היה להתרשם מהפעילות שלו באופן ברור ומיידי.

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

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

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

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

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

מתי משתמשים ב-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.

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

סיפור לקוח WebPals – המטרה: ביצועים

כשוובפאלס, המובילים בתחום הפרסום מבוסס ביצועים, צמחו בקצב מהיר בכל העולם, MoovingOn עזרה להם לשמור על הזמינות מאחורי הקלעים.

לקוח

קבוצת WebPals

https://www.webpals.com/

תחום פעילות

פרסום מבוסס ביצועים עבור מגוון לקוחות

אתגרים עיקריים

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

הפתרון של MoovingON

ניהול חיצוני של ה-NOC באמצעות צוות אנשי המקצוע של MoovingON וליווי בתהליכי ה-DevOps

כללי

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

עם יותר מ-400 עובדים, WebPals מספקת שירותים ללקוחות בכל רחבי העולם, מה שמחייב אותה לזמינות מערכות של 24×7 גם מול הלקוחות, וגם לצורך מערכות פנימיים כמו שירות לקוחות, ניהול תוכן ועוד.

האתגר

"לפני MoovingON הפתרונות שלנו התבססו על כלי ניטור בסיסיים שלא סיפקו לנו מידע מפורט, אלא רק ברמת הידיעה אם שרת למעלה או למטה", אומרת אליה ווסט, ראש צוות Web Production בחברת WebPals.

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

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

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

הפתרון

הפתרון של MoovingON כלל שירות ניהול רשת (NOC) ומקצועי בזמינות מלאה של 24x7x365. אנשי ה-NOC של  של MoovingON הם בעלי ניסיון רב, עוברים הכשרות באופן שוטף, ובשל החשיפה השוטפת למגוון בעיות הם יכולים להציע פתרונות בדוקים ובטכנולוגיות חדשות.
השירות של MoovingON מציע את הידע הזה ללקוחות החברה באופן מיידי, מה שחוסך לחברות את הצורך בגיוס והכשרה יקרים של עובדים בתחום, ויכולת ליהנות מהיכולות המקצועיות הגבוהות תוך זמן קצר. WebPals עובדת בסביבת AWS של אמזון, ומכיוון ש-MoovingON הם ספק מוסמך של אמזון, השילוב בין הצוותים בשתי החברות היה מהיר ויעיל.

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

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

היתרונות העסקיים

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

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

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

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

מגמות מעניינות בעולם ה 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 בשיפור מהירות וזמינות, תוך השקעה במשאבים רק בשביל זמינות ולא ניסיון לאזן בין התקציב ודרישות הגיוניות. לכן לפני תהליך של שיפור הזמינות, כדאי לקבוע מדדים מקובלים על כל צוותי הארגון מראש לגבי יעדי הזמינות, קצב העדכונים, מגבלות התקציב וכו'.

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