תחזוקת מערכות מחשוב מאתגרות: הגדרות, סכנות ומה אפשר לעשות

---

מאת: אורי אלון | מומחה מערכות מידע ותרבות ארגונית (M.A. Cultural Studies)

29.12.2024

---

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

רקע והגדרות

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

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

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

3. התיעוד של המערכת אינו עדכני

4. אין גישה לקוד המקור של אחד או יותר מרכיבי התוכנה

5. חלף פרק זמן ארוך מאז הותקן עדכון משמעותי אחרון למערכת

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

מצב קיים - אתגרים וסיכונים

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

המציאות בארגונים

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

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

אפשרויות הפעולה העומדות בפני הארגון

לראייתי, יש בפניך 4 אפשרויות בנוגע למערכת המאתגרת:

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

2. לבצע "ריענון" מסוים: קצת תיעוד, קצת תיקונים, קצת מעקפים

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

4. לבצע שדרוג או החלפה מוחלטים של המערכת המאתגרת לטובת מערכת חדשה

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

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

דרכי פעולה ופתרונות

לימוד והבנת המערכת המאתגרת

כדי ללמוד ולתעד מערכת מאתגרת מומלץ לבצע:

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

2. בצע איסוף של כל מידע קיים, מודפס או אלקטרוני (מיילים, מסמכים, מצגות), ונתח אותו

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

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

5. כלי AI יכולים לזהות דפוסים חריגים בלוגים ולאתר תקלות. שיטות Deep Learning יאפשרו ניטור רציף של ביצועי המערכת

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

קבע פגישה עם משתמשי המערכת כדי לשמוע שתי נקודות שהן הכי קריטיות מבחינתם. לדוגמה: "בין 10:00–12:00 המערכת איטית" (מריצים עיבודים? דווקא אז מבצעים עבודות תחזוקה? יש מה לעשות !) או "דוח הזמנות נתקע". גם אם אין גישה לקוד מקור, תוכל ליצור דוח חדש באמצעות כלי חיצוני.

ניתן לבצע סקר בקבוצת הווטסאפ של הצוות:

"היי לכולם, סקר קצר: מה הכי דחוף במערכת 'ניהול ספקים'? 1. שיפור תיעוד 2. טיפול בדוחות תקועים 3. קיצור זמני השבתה."

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

פתרונות טכנולוגיים ושיפורים אפשריים

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

היבטים ארגוניים ושיתופי פעולה

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

תקציבים ומשאבים

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

המלצות ליישום

מדיניות ארגונית

מומלץ שהנהלת הארגון תגבש מדיניות לגבי מחזור חיי מערכות מאתגרות:

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

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

לוח זמנים והקצאת משאבים להחלפה/הסבה מלאה.

פעולות להפחתת סיכונים

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

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

טיפול בנקודות חלשות בקוד, בממשקים, עיבוד או פלט, לעיתים באמצעות מעקפים או כלי low code \ no code.

ריענון נהלים וכתיבת מדריך למשתמש, כך שהשימוש יהיה מיטבי בתנאים הקיימים.

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

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

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

"אין להפעיל דו"ח הזמנות בין 10:00–12:00" עוד טרם השלמת את כתיבת המדריך המושלם למשתמש.

זה מצמצם נזק עד למציאת פתרון טוב יותר.

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

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

סיכום

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