תיק מניות

רשימת קריאה

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

לחיצה על כפתור "שמור", בתחילת הכתבה תוסיף את הכתבה לרשימת הקריאה שלך.
לחיצה על "הסר" תסיר את הכתבה מרשימת הקריאה.

לרשימת הקריאה המלאה לחצו כאן

חוב טכנולוגי: כיצד הוא נוצר ומה עלול לקרות אם מזניחים אותו?

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

קודים, מחשב
Sai Kiran Anagani on Unsplash

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

>> רוצים להצטרף ל-Appsflyer? הגישו מועמדות

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

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

צ׳אריטי מייג׳ורס, מנכ״לית Honeycomb, מחברת הספר Database Reliability Engineering ואחת מנשות ה-DevOps הידועות שהשתתפה בכנס DevOps Days תל אביב 2016. בכנס התייחסה מייג'ורס לחוב הטכנולוגי, וטענה שחשוב לתגמל ולהעריך מפתחים אשר עושים refactoring ומטפלים בחוב הטכנולוגי, ודואגים להוריד שורות קוד מאפליקציות אפילו יותר ממפתחים אשר רוצים אך ורק להתרכז בפיתוח פיצ׳רים חדשים ובקוד חדש. מייג'ורס אף הצביעה על האירוניה בכך שלרוב דווקא מפתחים שמתחזקים קוד סבוך, או עושים refactoring מקבלים פחות פרגון ואהדה.

אפספלייר, כנס
ויקטור לוי

סיפורי אימה של החוב הטכנולוגי

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

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

לא להיתקל בקיר

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

מחשב נייד
Ash Edmonds on Unsplash

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

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

לחברת AppsFlyer ניסיון רב בכל הקשור לצמיחה מהירה. כאשר הפלטפורמה שלהם, אשר מתמחה בניתוח ומדידה של קמפיינים שיווקיים במובייל, תפסה תאוצה ונכנסה ל- hyperscale, המערכת של AppsFlyer ״נאלצה״ להתמודד עם צמיחה מהירה בנפח התעבורה ממאות מיליונים של אירועים ביום ל55 מיליארד כיום. הגידול המשמעותי בנפח התעבורה הוביל את החברה להבין מהר מאוד כיצד צריך לבנות מערכות אשר יש להן גמישות, אלסטיות ויכולת התאוששות מתקלות (resilience), וחידדה את ההבנה כי כמה חשוב להתייחס בצורה משמעותית יותר למקומות במערכת בהם קיים חוב טכנולוגי.  הגישה הזאת היא הדרך בה AppsFlyer שואפת למקצוענות (או בלעז, craftsmanship), תוך יצירת תרבות של יוזמה, תכנון מוקפד מראש, ומצוינות הנדסית.

אפספלייר, כנס
ויקטור לוי

הגישה הנכונה לטיפול בחוב הטכנולוגי

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

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

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

ללמוד מניסיון של אחרים

חברה אשר מעוניינת להתמודד בצורה יעילה ונכונה עם החוב הטכנולוגי, יכולה ללמוד מהטיפים של חברת AppsFlyer:

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

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

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

 

בואו לעבוד איתנו:

>> Senior Data Engineer