איך מנהלי ה-System הפכו ל-DevOps Engineer?

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

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

במאמר זה אנסה לענות לפחות על חלק מתהיות אלה.

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

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

האתגרים והפתרונות

יש כאן מספר אתגרים:

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

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

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

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

אתחיל מהבעיה הראשונה: כלים כמו Puppet ,Chef ,Ansible או SaltStack, שבזכותם מנהלי System הופכים יותר ויותר להיות מומחי DevOps, מאפשרים להם להשקיע זמן רב יותר בתכנון של התשתיות ופחות זמן במשימות רוטיניות, שחוזרות על עצמן.

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

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

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

גם את הבעיה השלישית, של מתן ושירות יעיל בארגון, ניתן לפתור. זה נעשה עם כלים כמו MCollective ,Capistrano או Rundeck, כדי לתרגם פעולות Orchestration מורכבות לכפתור אחד שלוחצים עליו ומקבלים תוצאות. ELK (ר"ת Kibana+Logstash+Elasticsearch) מאפשר לתת BI ו-KPI ברמות של מוצרים שפעם היה צורך בחודשים רבים כדי להטמיע אותם, עם עזרה חיצונית.

פתרונות הקוד הפתוח לצד קהילה שצומחת בקצב מהיר יוצרים עולם בו כל אחד יכול לא רק להיות לקוח שצורך את המוצר, אלא גם מי שתורם לעצמו וחזרה לקהילה.
אפילו תאגידי ענק מסחריים כמו מיקרוסופט (Microsoft) מבינים את המציאות החדשה, ובכך ניתן לראות את התרומה שלהם ל-Open BSD, או למוצר הבא במשפחת מערכות ההפעלה לשרתים Windows Nano Server.

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

הכותב הוא מהנדס ויועץ DevOps. הוא משמש כמומחה DevOps באורבוטק, מטעם נס.