על DevOps וה DevOps toolkit

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

• מפתחים אחראים לכתוב קוד
• איש ה UX אחראי לעצב את חווית השימוש
• ה DBA מתמחה ב Database Systems
• ה QA בודק את המערכת
• איש ה Operations אחראי להתקין את התוכנה ולנטר אותה
• וכו'...

מקור: http://nealford.com/abstracts.html#cd

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

• איש ה UX רוצה להשיג את חווית השימוש הטובה ביותר - והמפתח רוצה לשחרר פיצ'רים מהר.
• איש ה QA רוצה שלמות במוצר - והמפתח רוצה לשחרר פיצ'רים מהר.
• איש ה Operations רוצה יציבות - והמפתח רוצה לשחרר פיצ'רים מהר.

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

שינוי #1: הגבולות בין אנשי ה QA והמפתחים החלו להיטשטש

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

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

שינוי #2: המעבר לענן ואוטומציה של התפעול

המעבר לענן הסיר מאנשי ה Operations בארגון כמה עיסוקים הרחוקים מאוד מהמפתחים: טיפול בחומרה ורשתות תקשורת - עולם שלם בפני עצמו. את החומרה והרשת מנהלים בצורה אוטומטית בעזרת תוכנה (להלן Virtualization ו Software Defined Networks) וכך התקרב העולם של אנשי ה Operations לעולם המתכנתים - עולם של כתיבת סקריפטים ~= קוד.    

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

היכולת של ה Operations להתמודד עם אתגרים אלו כקבוצה חיצונית לפיתוח - הפכה מורכבת יותר ויותר. חילופי ההאשמות והמתח בין הקבוצות רק הלך וגבר (להלן blaming culture).

שינוי שאנו נמצאים במהלכו כיום נקרא The DevOps Movement - ההכרה שהדרך הטובה ביותר להתמודד עם סביבות המחשוב המורכבות שנוצרו - הוא בשיתוף פעולה אמיתי בין Operations ל Developers.

מקור: ThoughtWorks Radar - מארס 2012

 

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

מקור: ThoughtWorks Radar - נוב' 2015

 

עבודת ה Dev-Ops בארגון

בשלב הזה אני לסקור את העבודה שיש בפני ה Operations וה Dev (וגם קצת IT וגם קצת QA) בארגון. אני יכול להתחיל בהצהרות ברמה גבוהה "לדאוג ליציבות המערכת". הצהרות אלו הן נכונות - הן אם לא תמיד כ"כ מוחשיות. מה כן מוחשי? כלים ותהליכים. אספתי את סוגי הכלים והתהליכים הקיימים בעולם Dev-Ops לכדי רשימה, ואני הולך לפרט לגבי כל קטגוריה בנפרד. אני אציג תמונה (/ "סיפור") מציאותית - אך כמובן לא יחידה: ניתן לתאר את התהליכים הללו בצורות שונות, ולאנשים שונים וארגונים שונים יש תפיסות שונות לגבי גבולות הגזרה בין התהליכים / הכלים / ותחומי-האחריות השונים. אני לוקח כמה הנחות בסט הכלים שאראה:

• אני מניח שמדובר ב Deployment בענן, ולא ב On-Premises (קרי: אין ניהול של חומרה ורשת פיסיים) - ואני מתמקד ב AWS (עננים אחרים הם דיי דומים בהיבט זה).
• אני מניח שמדובר באפליקציית ווב.
• אני מניח ש Docker (או פתרון אחר של Linux Containers) אינו מעורב - אחרת התמונה תשנה במידת-מה.

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

אם אתם כבר בתעשיה - אני מקווה שתמונה זו תוכל להשלים "חורים" שאולי חסרים לכם.

       

המורכבות של Stack מודרני, מול Stack בן עשור. מקור: https://goo.gl/9yCLtp

לרבים מההיבטים שאתאר (למשל: Logging, Version Control, וכו') יש היבטים ברורים מאוד של פיתוח: קביעת conventions לעבודה, למשל -  בד בבד עם היבטים של תפעול (התקנה ותחזוק של השרתים, גיבויים וכו').

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

כלים "פנימיים"

אלו הכלים שלרוב משמשים את הפיתוח. מישהו צריך לנהל ולתפעל אותם. ה"מישהו" הזה, הוא הרבה פעמים צוות ה IT) Operations). בסטארט-אפים קטנים - הרבה פעמים האלמנטים הללו מנוהלים ע"י המתכנתים עצמם.

דוגמאות לכמה כלים בכל קטגוריה

Issue Tracking

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

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

Jira (ויש מתכנתים האומרים: ״Jifa״) הוא כנראה הכלי הנפוץ ביותר, שמכסה גם היבטים של ניהול פרויקטים ובאגים - אך יש גם כלים אחרים.

Version Control

בסטארט-אפים מקובל בעיקר לעבוד עם Github.com - ולקבל משם שירותים מנוהלים של ניהול קוד.
ארגונים גדולים, יותר מקובל לעבוד עם Git ישירות או עם GitHub Enterprise (או החלופות שלו) - תוכנה שיש להתקין ולנהל לבד, עם היכולת לאבטח בצורה יותר טובה.

מלבד ניהול השרת של ה Version Control, יש עניין של ניהול התוכנה עצמה: ניהול ה Repositories, וההרשאות (האם אתם בודקים כל תקופה שעובדים שעזבו הוסרו מהמערכת?), הכשרה לעובדים (לא כולם מכירים את Git), ופתרון בעיות ("אופס... עשיתי force-- למשהו שגוי....").


Build

את הקוד צריך לקמפל (במקרה של Java, Go, #C, וכו') - או שלא (במקרה של רובי, Python, או ג'אווהסקריפט).
לרוב יהיו לנו בדיקות (יחידה, אינטגרציה, ביצועים, אבטחה) אוטומטיות - שירוצו כחלק מתהליך ה Build.
תוצרי הקוד (תמונות, קבצי JavaScript, קבצים בינאריים) לעתים קרובות עוברים עיבוד נוסף: דחיסה / אופטימיזציה - לתמונות, minification / obfuscation ו unification לקבצי ג'אווהסקריפט, או bundling לקבצים בינאריים (למשל: אריזת קבצי jar. כקובץ war. או ear. - בעולם הג'אווה).

את תהליך ה Build לרוב מריצים על כל submit / push של קוד ל Version Control - על מנת לאתר תקלות בשלב מוקדם ככל האפשר. באופן זה העלות לתקן את הבעיות - פחותה.

בטעות, יש כאלו שקוראים לתהליך ה Build בשם "Continuous Integration", ולשרת ה Build - כ "CI Server". זה שימוש שגוי בטרמינולוגיה: Continuous Integration הוא תהליך בו מגבירים את תדירות האינטגרציה בין המפתחים השונים. למשל: כל מפתח מבצע merge של הקוד שלו חזרה ל master / trunk - כל יום!

ו Git Flow? - הוא כבר לא כ"כ באופנה. זו בערך הגישה ההפוכה לגישה של Continuous Integration.
בעולם ה Build יש כלים ברמות שונות: Jenkins או TravisCI הם Build Servers שמנהלים את ה Build Pipeline.
כלים כמו Maven, SBT, Ant, או Gradle (כולם מעולם הג'אווה) - הם כלים להגדרת המיקרו של ה build (וניהול תלויות). דומים יותר ל Make או Rake.
בעולם הג'אווהסקריפט משימות מסוימות מבוצעות עם כלים כמו Grunt, Gulp, או npm - ואת משימת האריזה עם כלים כמו webpack או Browserify.


Artifact Management (בקיצור AM)

תוכנת AM היא כזו שעוזרת לנהל תוצרי תהליך ה-build (למשל: קבצים בינאריים, Gem Files, או Images של VM) בצורה: מסודרת, מאובטחת, Highly Available, ו Durable (כלומר: יש גיבויים).

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

AM יכולים לנהל תוצרים פנימיים שנוצרו ע"י הארגון, או Caching לתוצרים חיצוניים כמו ספריות Open Source (בכדי לקצר זמני הורדה שלהם ברשת). הרבה פעמים יהיו בארגון כמה כלי AMs שונים (למשל: תוצרי ג'אווה או רובי, תוצרי AWS, ותוצרי Linux).


Development Environment Management 

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

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


Collaboration

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

כלל קטן: אם אנשי ה Operations מתחזקים את כלי ה Collaboration אך לא משתמשים בהם - אין לכם תרבות של DevOps בארגון. שקיפות ושיתוף בין פיתוח ו Operations - זה הבסיס.

כלי "Production"

את הכלים הללו לרוב מפעיל צוות שנקרא בארגונים גדולים בשם ״Web Operations״. זו נחשבת התמחות שונה מצווות ה IT Operations.

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

כשעבדתי ב SAP למשל, צוות ה IT Operations ישב איתנו ונקרא "DevOps". הם ניהלו את כל הכלים הפנימיים, הדריכו ותמכו במפתחים וממש עזרו להם. הצוות הזה הכיר Git, Jira, ו Maven - יותר טוב מכולם.
צוות ה Web Operations נקרא "Hosting", ישב בגרמניה והיה מאוד מרוחק מאיתנו - פיסית ומנטלית. אם השתקפה בעיה ב Monitoring - מישהו היה מתקשר, אבל מעבר לזה הקשר ביננו היה חלש, ולא היה הרבה מה לעשות בנידון. זה היה תת-ארגון אחר. לכלי ה Monitoring למשל, לא הייתה לנו גישה. אפילו לא לצפייה. ממש לא DevOps Culture...

דוגמאות לכמה כלים בכל קטגוריה

 Web/HTTP

בקטגוריה זו יש לרוב יהיה שימוש ב 2 או 3 מתוך תתי הקטגוריות הבאות:

1. HTTP Server - עבור הגשת Static Content ו/או ניהול התעבורה עבור Technology Stack שאינו multi-threaded מטבעו. כלומר: PHP, Ruby, Python. הכלים הנפוצים בקטגוריה זו היא Nginx ו Apache httpd.
2. Application Server - סביבת ריצה לאפליקציות ווב. בעולם הרובי Applications Servers נפוצים הם Puma, Unicorn, ו Raptor. בעולם הג'אווה הם יכולים להיות Tomcat, Jetty, או Glassfish.
3. Content Delivery Network (בקיצר CDN) - שהיא יעילה אף יותר מ HTTP Server בהגשת Static Content, אך יש לעתים סיבות להשתמש בשניהם.

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

Configuration Management

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


Packaging

ה Packaging מטפל באריזת ה VM Image שממנו ניצור instances של מכונות בענן.
אם אתם עובדים בענן כלשהו (אמזון, Azure, או אפילו VMWare) - סביבת הענן תאפשר לכם לייצר Image ממכונה.

כלים כמו boxfuse או packer מאפשרים לכם לייצר מאותה המכונה Images מסוגים שונים (למשל: אחד ל Azure ואחד ל AWS במקביל), וגם ליצור Images קטנים ויעילים יותר (ע"י זיהוי התלויות הנדרשות ובניית "סביבת מערכת הפעלה" מספיקה לצרכים הספציפיים).
Image מוקטן שכזה מתאים ל Immutable Deployments (להלן הפוסט על כלי ניהול תצורה), ומגיע על חשבון החופש להתקין בקלות עוד כלים על המכונה במהלך הדרך.

למרות שאני מציג את ה Packaging כקטגוריה בלתי-תלויה בכלי ניהול תצורה - לרוב משלבים בתהליך ה Packaging כלי ניהול תצורה, שילוב שלרוב הוא מובנה בכלי ה Packaging.


Deployment

"מה הבעיה לעשות Deployment?!" - היא השאלה הראשונה כאשר עוסקים בקטגוריה זו.
"אני פשוט הולך ל UI של אמזון, בוחר image, ומאשר - תוך 2 וחצי דקות השרת למעלה".

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

• כיצד להתקין שרתים חדשים מבלי לפגוע ב Traffic הקיים? לא Downtime ולא שיהוק.
• אם אנו עושים זאת בהדרגה, כיצד מתמודדים עם מצב הביניים בו יש כמה שרתים בגרסה n, וכמה שרתים בגרסה n-1 החיים זה לצד זה?
• מכיוון שמדובר ב cluster, כיצד עושים זאת עם כל הגדרות ה Load Balances, רשת, אבטחה - ומבלי להתבלבל. ה UI הרגיל של אמזון כבר לא כ"כ טוב לבעיה הזו.
• מה עושים במצב של כשל? מתי מזהים אותו וכיצד - ואיך עושים Rollbacl? (לא נחכה לתיקון קוד עם בעיה חמורה בפרודקשיין, ולא משנה עד כמה המתכנתים שלנו זריזים).

בגדול, יש שתי "אסטרטגיות: עיקריות לביצוע Deployment:

• Rolling Deployment -
  • התהליך (נניח שהשרת שלנו רץ על m nodes):
    • ניקח node אחד ואז:
      • ננתק אותו מה LB 
      • נוודא שכל ה requests שבתהליך סיימו להיות מטופלים
      • נתקין את הגרסה החדשה
      • נחבר אותו בחזרה ל LB וננטר אותו לזמן קצר לראות שהכל בסדר.
    • נחזור על כל התהליך הזה עוד כ m-1 פעמים.
  • ל Rolling Deployments יש ייתרון של חסכון במשאבים (צריך עוד שרת אחד, אפילו אם יש לנו 100 nodes), אבל הוא יכול להיות תהליך ארוך - ו rollback הוא קשה וארוך גם כן.
• Blue/Green Deployment - 
  • התהליך (נניח שהשרת שלנו רץ על m nodes - "ה cluster הכחול"):
    • ניצור cluster חדש ("ירוק") זהה בחומרה ל cluster המקורי - ונתקין עליו את הגרסה החדשה.
    • ננתב חלק קטן מה traffic ל cluster החדש וננטר לזמן קצר. הכל בסדר? נחליף ברגע אחד את ה cluster הירוק להיות ה cluster הפעיל.
      • ניתוב ה Traffic יכול להיעשות באסטרטגיה של DNS cutover, באמזון - זמינה גם אסטרטגיה בשם swap auto-scaling groups, ויש גם אסטרטגיות אחרות.
    • ה cluster הכחול ימשיך לחיות עוד זמן מה (החיוב באמזון למכונות הוא ע"פ שעה עגולה של שימוש). אם נגלה בעיות בגרסה החדשה נוכל לחזור ל cluster הכחול - ברגע.
  • Blue/Green Deployment דורש יותר משאבים - אך הוא בטוח יותר, ומאפשר Rollback מהיר.

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

לרוב ספקי הענן יש כלים משלהם לפעולות Deployment (ובכלל ניהול ה Deployment Pipeline) - אך הכלים החיצוניים עדיין נחשבים טובים יותר.

הערה: Jenkins הוא לא כלי מוצלח לניהול Deployment. נכון: גרסה 2.0 שלו הציגה קונספט של "Pipeline as code", אך קונספט זה ממשיך לעקוב אחר המודל הקיים והסבוך של pipelines של Jenkins והגמישות בו מבוססת על Plugins.

Jenkins הוא סבבה כנראה ל build pipeline, כך בכל הקשור ל deployment - מומלץ להיצמד לכלים ייעודיים.

כדאי להכיר: אלו סט הכלים של HashiCorp - ארגון מוערך מאוד שהוציא כמה כלים מאוד מעניינים (דגש על Vagrant ו Consul) בתחום. חשוב גם להיזהר מהנטייה האישית "לאסוף סריות": לא כל כלי של HashiCorp הוא בהכרח מתאים לכם. בוודאי שלא!

RDBMS Migration

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

להזכיר: בזמן ה Deployments (אם רוצים zero downtime) יהיו שלבים בהם ירוץ קוד חדש וישן זה לצד זה - ושניהם מול בסיס נתונים אחד (זה לא ריאלי בד"כ לרפלק את בסיס הנתונים לצורך deployment. יותר מדי סיכונים והשקעה).

ניתן לבחור ב-2 גישות: 

• קוד תואם לאחר שיתמוך ב-2 הסכמות (השקעה גדולה). את המיגרציה ניתן לעשות לאחר עדכון הקוד (סיכון).
• סכמה תואמת לאחור - כלומר רק תוספות ולא מחיקות או שינויים (הגישה הנפוצה). את המיגרציה יש לעשות לפני עדכון הקוד, בשלב מוקדם של ה deployment.

עבור migrations יש כלים רבים. חלקים מגיעים כחלק מה Framework (כמו ב !Ruby On Rails, Play, או Django). ישנם כלים כמו Flyway או Liquibase שאינם תלויים בשפת תכנות או Framework ספציפי.

ה Migration עצמו הוא סכנה ליציבות המערכת: תקלה בו יכולה להיות בעיה קשה.

סיכון נוסף הוא שינוי של טבלאות גדולות במיוחד (עשרות או מאות מיליוני רשומות?) או פעילות במיוחד (הרבה locking). פעולות migration שכזו עשויה להתארך לאורך שעות - ולפגוע לאורך כל הזמן הזה בביצועי המערכת.

כלים כמו LHM או Table_migrator מצמצמים סיכונים ע"י העתקת הטבלה הצידה, ביצוע ה migration, ואז החלפתה (rename) - קונספט דומה ל Blue/Green Deployment - רק שצריך לנהל delta של השינויים שלא נכנסו לטבלאת העותק בזמן ה migration - ולעדכן אותם מאוחר יותר.

Monitoring

אין דיי לומר על עולם זה, ה Monitoring הוא גם עין ימין וגם עין שמאל שלנו - על סביבת הפרודקשיין.
פעם, כשחדר השרתים היה במשרד היה ניתן לקפוץ אליו - ולשמוע את המאוורים מסתובבים. היום גם את זה אי אפשר ;-).

כלי ה Monitoring הם אלמנט חשוב לתפעול, ולרוב יהיה לנו Monitoring בכמה רמות שונות (מערכת, אפליקציה, Proactive Monitoring, וכו'.) - ייתכן וכל רמה בכלי שונה.

כתבתי כבר בעבר פוסט על New Relic - הכלי האהוב עלי בתחום: על Performance Monitoring ו New Relic.
כתבתי גם פוסט בשם Monitoring: מבוא ל Graphite ושימוש ב Time-Series - המתאר כלים ל custom monitoring (בהיבט של time series).

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

תת-קטגוריה קרובה אחרת היא הנושא של Event Management: בהינתן מדדים כאלו ואחרים - הפעל response שנקבע מראש (ונבדק). למשל: restart ל service, הריגת טרנזקציה מסוימת ב DB, הגדלת מספר השרתים, וכו'.


Logging

לכתוב מהקוד ללוג - זו לרוב פעולה פשוטה למדי: בוחרים ספריית Logging, מסכימים על כמה כללים - וכותבים.

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

הכלים הנפוצים לניהול לוגים הם ה ELK Stack (קיצור של ElasticSearch, LogStash, ו Kibana) או לחלופין Splunk או SumoLogic (שלא כוללים את איסוף הלוגים - LogStash או מוצרים חלופיים).

יש גם תת קטגוריה של Error Tracking - שהם כלים ייחודיים לניתוח תקלות משמעותיות במערכת (מול לוגים - שכוללים את כל המידע וגם info, traces, וכו'). כלים מוכרים בקטגוריה זו הם Airbrake, Sentry, ו Raygun.

יכולות ייחודיות לכלים אלו הם סנכרון עם עדכוני קונפיגורציה / תוכנה - וניתוח ה impacts שלהם מבחינת צפיפות ה errors, חיתוך ע"פ id של משתשמש (שאנחנו סיפקנו) בכדי לנסות ולאתר מדוע שימוש מסוים גורר בעיות - וכו'.

מקור: Sounil Yu

 

Security

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

• מתחילים עם Firewall - שבדרך כלל ספק הענן יספק.
• אם המערכת שלכם עובדת על גבי HTTP, קרוב לוודאי Web Application Firewall (בקיצור WAF) - כמו Cloudflare, אינקפסולה, או BigIP (של F5).
• דרך כלים ל Authentication ו/או Federated Identity Management (בקיצור FIM) כמו PingIdentity, OKTA, או Auth0.
• כלי Intrusion Detection System (בקיצור: IDS) - כמו Snort, או Trend Micro's Deep Security.
• כלים ל audit בגישה ל Production כמו ObserveIt או CyberArk.
• כלי SIEM - כלי לניהול לוגים בהיבט האבטחה, כלים כמו ArcSight, QRadar, או Splunk (שהוא גם "חזק" בעולם ה Security).
• כלים ל Security Static Code Analysis המחברים לתהליך ה build כגון Checkmarx או Fortify.
• ועוד...

בארגונים יותר גדולים, כל הנושא של כלי ה Security מופקד ביחיד צוות Operations מיוחד, שמתמחה בנושא.
בארגונים קטנים יותר - זה היה צוות ה Web Operations או אפילו המפתחים.

לכאורה, ניתן לכתוב פוסט מקביל לזה - רק בהיבט האבטחה.  

סיכום

עוד פוסט שחששתי שלא יהיה לי מה לכתוב בו - אך התארך מעבר הצפוי :)
נושא ה Operations וה Production הוא עולם בלתי נגמר.

תנועת ה DevOps שמשפיעה על כלל התעשיה (שלב א': שינוי ה Title של אנשי ה Operations - אך יש גם את השלבים הבאים) - משנה את העולם.

עוד כוח שמשנה את התמונה הוא טכנולוגיית ה Linux Containers (ובחזיתה: Docker), גישה החותרת ל Fully Immutable Deployment - גישה שעשויה לשנות כמה מהתהליכים ויחסי-הכוחות בעולם זה.
תוצר לוואי של גישת ה Containers היא החתירה ליצירת כלי Infrastructure Management חדשים (כמו Mesos, Tectonic, או Atlas), שלא מבוססים על ספקי הענן  - מה שעלול לגרום לעוד כמה תזוזות.


שיהיה בהצלחה!

---

לינקים רלוונטיים

DevOps Awesome Links - כמה קישורים מעניינים!

DevOps From the ground up Deep Dive into Blue/Green Deployments on AWS - על אסטרטגיות Deployment.

ההבדל בין Packer ל Vagrant - מאמר + דברים של מיטשל האשימוטו (Hashi)  

Cybersecurity Market Review - סוקר הרבה כלי Security במגוון קטגוריות