✕ סגור 
צור קשר
תודה על ההתעניינות .

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

הגיע הזמן להוסיף את ה ops ל dev

אסף סובול
|
Mar 8, 2017
alt="blogs"
alt="blogs"
alt="blogs"
Events
Event
title="Google"

בשנים האחרונות חל שינוי בדרך בה אנו מפתחים ובודקים אפליקציות ומעבירים אותן לייצור. באופן כללי, הדרך שבה אנו צורכים אפליקציות השתנתה בכמעט 180 מעלות. לכל אלה יש השלכה ישירה על תפעול ה-IT הארגוני הקלאסי. ארכיטקטורה ארגונית טיפוסית כוללת בד"כ: סביבות פיתוח רבות, שפות פיתוח שונות,  דאטהבייסים שונים (Structured, Unstructured), Micro-Services מסוגים שונים, תשתיות מבוססות מערכות On Premise או ספקי ענן שונים, Containers, טכנולוגיות מובייל (Front end – Back end) ועוד ועוד.

בקיצור, במקום שהחיים שלנו יהיו יותר פשוטים לניהול, הם נהיו רק יותר מסובכים…

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

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

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

אז איך מבטיחים שלא שכחנו את ה- Ops? איך מטפלים בשני חלקי המשוואה?

  • ‍אמצו את גל הטרנספורמציה הדיגיטלית: הענן הוא המנוע להזדמנויות חדשות. אם פעם נדרשו תהליכים ארוכים לבדיקה ושחזור הבאג, הרי שהיום הענן מאפשר אוטומציה ללא פשרות. אין שום סיבה להנציח את ה-silos של פעם, במקום זאת, שימו את נתוני התפעול שלכם במקום אחד, על תשתית Big-Data והשתמשו בכלי ניהול ממוקדי machine-learning שיעשו את העבודה השחורה בשבילכם.
  • נטרו את חווית המשתמש: בצעו Monitoring בדיוק במקום שמשפיע ביותר על צריכת השירות- בחוויית המשתמש. אומנם, רעיון ניטור חווית המשתמש אינו חדש, האתגר היה היישום הטכני, אבל היום בעזרת טכנלוגיית ענן וכלי ניטור next-generation, אפשר ליישמו בקלות רבה ובעלות לא גבוהה (משלמים רק על מה שמשתמשים, כמו כל דבר אחר בענן).
  • גישת It's all about the Log: בכל אפליקציה, חומרה או שירות יש לוגים (Log). הבעיה שאנחנו מגיעים אליהם רק בתחקור התקלה בדיעבד, וגם אז לא קוראים הכל, בשל כמויות המידע העצומות. אבל (וכאן גם הסתירה הפנימית), הרי ידוע שהאמת חבויה בלוגים, כלומר היכולת להבין מה השתבש במקור.

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

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

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

ב-21 במרץ יתקיים יום הענן של אורקל Oracle Cloud Tech Day, בו תשיק החברה רשמית בישראל את הדור הבא של טכנולוגיות הענן שלה ותציג חידושים רבים ב-IaaS ו-PaaS. בין היתר יוצג גם OMC- Oracle Management Cloud, הדור הבא של כלי הניטור, הניהול והאנליטיקה, המשולבים לכלי מתקדם המסופק כשירות על Oracle Cloud. הכלים מיועדים לסביבות הטרוגניות של היום: on-premises, הענן של אורקל ושירותי ענן של צד שלישי.

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

בשנים האחרונות חל שינוי בדרך בה אנו מפתחים ובודקים אפליקציות ומעבירים אותן לייצור. באופן כללי, הדרך שבה אנו צורכים אפליקציות השתנתה בכמעט 180 מעלות. לכל אלה יש השלכה ישירה על תפעול ה-IT הארגוני הקלאסי. ארכיטקטורה ארגונית טיפוסית כוללת בד"כ: סביבות פיתוח רבות, שפות פיתוח שונות,  דאטהבייסים שונים (Structured, Unstructured), Micro-Services מסוגים שונים, תשתיות מבוססות מערכות On Premise או ספקי ענן שונים, Containers, טכנולוגיות מובייל (Front end – Back end) ועוד ועוד.

בקיצור, במקום שהחיים שלנו יהיו יותר פשוטים לניהול, הם נהיו רק יותר מסובכים…

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

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

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

אז איך מבטיחים שלא שכחנו את ה- Ops? איך מטפלים בשני חלקי המשוואה?

  • ‍אמצו את גל הטרנספורמציה הדיגיטלית: הענן הוא המנוע להזדמנויות חדשות. אם פעם נדרשו תהליכים ארוכים לבדיקה ושחזור הבאג, הרי שהיום הענן מאפשר אוטומציה ללא פשרות. אין שום סיבה להנציח את ה-silos של פעם, במקום זאת, שימו את נתוני התפעול שלכם במקום אחד, על תשתית Big-Data והשתמשו בכלי ניהול ממוקדי machine-learning שיעשו את העבודה השחורה בשבילכם.
  • נטרו את חווית המשתמש: בצעו Monitoring בדיוק במקום שמשפיע ביותר על צריכת השירות- בחוויית המשתמש. אומנם, רעיון ניטור חווית המשתמש אינו חדש, האתגר היה היישום הטכני, אבל היום בעזרת טכנלוגיית ענן וכלי ניטור next-generation, אפשר ליישמו בקלות רבה ובעלות לא גבוהה (משלמים רק על מה שמשתמשים, כמו כל דבר אחר בענן).
  • גישת It's all about the Log: בכל אפליקציה, חומרה או שירות יש לוגים (Log). הבעיה שאנחנו מגיעים אליהם רק בתחקור התקלה בדיעבד, וגם אז לא קוראים הכל, בשל כמויות המידע העצומות. אבל (וכאן גם הסתירה הפנימית), הרי ידוע שהאמת חבויה בלוגים, כלומר היכולת להבין מה השתבש במקור.

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

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

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

ב-21 במרץ יתקיים יום הענן של אורקל Oracle Cloud Tech Day, בו תשיק החברה רשמית בישראל את הדור הבא של טכנולוגיות הענן שלה ותציג חידושים רבים ב-IaaS ו-PaaS. בין היתר יוצג גם OMC- Oracle Management Cloud, הדור הבא של כלי הניטור, הניהול והאנליטיקה, המשולבים לכלי מתקדם המסופק כשירות על Oracle Cloud. הכלים מיועדים לסביבות הטרוגניות של היום: on-premises, הענן של אורקל ושירותי ענן של צד שלישי.

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

לפרטים נוספים ויצירת קשר עם נציג אורקל

תודה הודעתך התקבלה

הודעתך לא התקבלה - נסה שוב מאוחר יותר

אסף סובול

הירשם לרשימת הדיוור של IsraelClouds

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

מילון מונחיםהשירותים שלנו תנאי שימושהרשמה לניוזלטרמדיניות פרטיות