ניתן לשייך את הוויכוח בעד ונגד החלת עדכוני תוכנה על מחשבים תעשייתיים לקטגוריה של מלחמות קודש ממש. לשני הצדדים יש סיבות טובות להתנהל בצורה זו או אחרת. אז מה עושים? במאמר זה מציג סרגיי ברזנסקי, מנכ"ל נקסוס פתרונות מחשוב, את גישתו לנושא, ומפריך את הטענות העיקריות נגד החלת העדכונים.
כל מי שנתקל אי פעם במסך המעצבן של מערכת ההפעלה, הדורש להפעיל את המחשב מחדש לצורך החלת עדכונים, יודע את התסכול הרב העומד מאחורי הפעולה הפשוטה הזו, לכאורה. עשרות חלונות פתוחים, מסמכים שלא נשמרו, דואר אלקטרוני ואתרי אינטרנט פתוחים וכו' אלה קר מעט הסיבות להימנע מאיתחול המחשב באותו הרגע. נכון, המצב לעיתים מאוד מתסכל, ואף מביך, אך זה עוד כלום לעומת הצורך לאתחל שרתים או תחנות עבודה קריטיות התומכות בקו ייצור. המצב שם הופך להיות בעייתי בהרבה, שכן לעיתים קרובות קיים צורך לבצע המון פעילויות הכנה לפני הפעלתו מחדש של המחשב. ולעיתים קרובות, הפעלת מחשב מחדש הופכת להיות משימה בלתי אפשרית של ממש.
לכן, במיוחד בסביבות התעשייה, מנהלי רשת רבים מחליטים, ובצדק, פשוט לבטל את החלת העדכונים על כלל המחשבים בארגון. מצד אחד, אפשר להבין אותם, הרי הפתגם הידוע של אנשי מחשבים - "אם זה עובד, אל תיגע" - מצדיק את עצמו במקרים רבים. נדון על כך בהרחבה בהמשך.
תחילה, הייתי רוצה להציג את הסיבות העיקריות, המניעות את אנשי ה-IT במפעלי התעשייה ללכת על השיטה ה"בטוחה" ולבטל את החלת העדכונים
- "פעם שידרגתי מחשב אחד, והוא הפסיק לעבוד" - אכן, החלה של עדכון כזה או אחר משפיעה לרעה על המערכת כולה - פתאום, דברים מסויימים עלולים להפסיק לעבוד, או לעבוד בצורה לא נכונה. וככל שמהות העדכון גדולה יותר, כך גדלים הסיכונים של השבתה כללית של המחשב. אוכל להביא דוגמה קלאסית - Windows XP SP2. לעיתים קרובות, מערכות תעשייתיות הפסיקו לעבוד לאחר שדרוג המחשבים ל-SP2. לא ארחיב בשלב זה את הסיבות לכך, נדון עליהן בהרחבה בהמשך הכתבה. אבל הטענה מהותית ודורשת התייחסות מעמיקה
- "אין דרך לחזור מהעדכון" - לעיתים רחוקות מאוד, עדכונים אכן מגיעים ללא יכולת הסרה, כך שביצוע העדכון, לכאורה, מהווה "כרטיס לכיוון אחד"
- "אין חיבור לאינטרנט ברצפת הייצור" - הטענה של מנהלי רשת רבים היא חוסר היכולת להביא את העדכונים למחשבים מסויימים, או לכלל המחשבים ברצפת הייצור עקב חוסר חיבורם לרשת המפעלית או לאינטרנט. הדבר נכון במיוחד במקומות בהם קיימת הפרדה של מערכות קריטיות משאר הרשת המפעלית
- "אין צורך בהחלת העדכונים" - בכן, הטענה העיקרית של אנשי המכשור והבקרה. לטענתם, המערכת נועדה לשרת את קו הייצור למשך שנים רבות. להבדיל ממשרדים, בהם תדירות החלפת התוכנה היא מדי כל שנתיים-שלוש, המערכות במפעל הייצור מתוכננות לעבוד שנים רבות, ואף עשרות שנים, ללא החלפה או שדרוג מהותי כלשהו. אם כך, למה לשדרג?
- "הסיכונים גבוהים מדי" - יישום ממוחשב כלשהו, הפועם בליבה של מערכת מורכבת של קו הייצור, רצוי שימשיך לעבוד באותה הצורה כפי שתוכנן מראש. אי לכך, אם המערכת פועלת כשורה נכון לרגע זה, כל התערבות חיצונית עלולה לפגוע בתקינותה של המערכת, ובטוח שלא תהווה שיפור. לטענת המהנדסים, הסיכונים הכרוכים בהחלת העדכונים גבוהים על התועלת.
- "אין זמן לבצע בדיקות" - כל שינוי במערכת, אף קטן ביותר, דורש לבצע בדיקות מקיפות אל מנת לוודא כי פעילות המערכת לא נפגמה עקב השינוי. תדירות שחרור העדכונים החדשים גבוהה יחסית (למשל, עבור מערכות מבוססות Windows, מדי שבוע משוחררים עדכונים חדשים), ולכן המשאבים הדרושים לביצוע העדכונים עלולים לצאת מכל פרופורציה, ובהיעדר כוח אדם לגרום להדחה של משימות חשובות יותר
- "למה אני צריך את זה" - הטענה שנשמעת לעיתים קרובות. מנהלי רשת שונים מוצאים סיבות שונות ומגוונות לחוסר כדאיות של תהליך החלת העדכונים
ובכן, לכל הטענות שהבאתי יש בסיס מוצק. אני עוסק במערכות מחשוב תעשייתי שנים רבות, ויצא לי לא פעם אחת להיווכך בצדקתן. לכן, לא אנסה אפילו להפריך את העובדות. במקום זאת, אביא מספר דוגמאות מהמקרים בהם יצא י לטפל באופן אישי.
שעון חורף או שעון קיץ?
כפי שידוע לכולנו, ארץ ישראל אינה המקום המסודר ביותר בעולם מבחינת התנהלות שעון קיץ. רק בשלוש השנים האחרונות, מדיניות שעון קיץ הוחלפה מספר פעמים, ולאור המצב הפוליטי הנתון, ככל הנראה, המגמה תימשך. מיקרוסופט וחברות אחרות דואגות להוציא עדכונים מבעוד מועד, אשר תקפידם להתאים את הגדרות המחשב למדיניות שעון הקיץ הנוכחית. אך במידה והעדכון לא מוחל על כלל המחשבים בארגון, אנו עלולים להיות עדים למצבים מאוד לא נעימים. למשל, מאחד מן המפעלים הגדולים בארץ, בו מנהל הרשת מתעקש על ביטול עדכונים למחשבי רצפת ייצור, מדי חצי שנה אנו מקבלים הזמנה דחופה לעזור בפתרון בעיית השעון ש"קפץ שעה". ההשלכות לכך רציניות ביותר, החל מסטטיסטיקה לא נכונה של צריכת חומר גלם. במקרה אחד, אי התאמה של השעה במחשב לבין השעה בבקר התעשייתי אליו הוא מחובר גרמה לבעייה מאוד רצינית, שהביאה כמעט עד כדי קריסת קו הייצור ונזק של מאות אלפי דולרים.
כלומר, אי הרצון להסתכן בנזק הפוטנציאלי הפך לנזק מוחשי של ממש. הפתרון לבעיה של סנכרון שעונים כלל התקנה ידנית של העדכון על כלל המחשבים בארגון, ולקח מספר ימים עד לפתרון המלא של התקלה. בנוסף לכך, נאבדו נתונים סטטיסטיים של חודש עבודה.
האם היה אפשר לעשות אחרת? ובכן, כמובן. להחל את העדכון של מערכת ההפעלה מבעוד מועד.
מותר לשמוע מוזיקה במחשב בקרה?
הסוגיה הנוספת שברצוני להעלות כאן זה נושא אבטחת המידע המפעלית. נכון, שלרוב האירגונים התעשייתיים היום כבר קיים מערך אבטחת מידע מינימאלי. למשל, ניתוק רשת המחשבים של רצפת הייצור מהרשת המנהלתית. כמובן, שניתן לצמצם את הסיכון של פגיעה מבחוץ במערכות על ידי ניתוק הרשת הפנימית מהאינטרנט. אבל האם זה פותר את הבעיה באופו סופי?
במפעל אחר, שבו אנו מספקים שרותי מחשוב תעשייתי, עובד תמים הביא מהבית כונן קשיח עם מוסיקה, אותו הוא מצא לנכון לחבר למחשב בחדר הבקרה, על מנת להוסיף קצת טעם למשמרת הלילה. התוצאה אכן הוסיפה טעם למשמרת הלילה, ולעוד מספר משמרות לאחר מכן. הסתבר, שהדיסק היה נגוע בוירוס מחשב, אשר הדביק את המחשב, ודרכו את שאר המחשבים ברשת הייצור. את כולם, תוך פחות מ-5 דקות. ובכן, תשאלו אותי, מה הקשר בין פרצה באבטחת המידע ואשמתו של העובד לבין העידכונים שלא הוחלו על מחשבי המפעל? מסתבר, שהקשר מאוד פשוט. הוירוס בו נדבקה רשת המחשבים נקרא Sasser, וצורת ההפצה של וירוס זה ניצלה חור אבטחה במערכת הפעלה Microsoft Windows XP, אשר זוהה ותוקן(!) על ידי חברת מיקרוסופט כ-3 שבועות לפני שהווירוס יצא לאור, וכחצי שנה לפני שהמחשב במפעל הודבק על ידי העובד. ניתן היה למנוע את הפצת הווירוס בארגון רק על ידי התקנה של העדכונים הקריטיים למערכת ההפעלה מבעוד מועד.
ובכן, הבאתי רק 2 מהדוגמאות שמצדיקות את הצורך בהחלת עדכונים במחשבים, אך קיימות דוגמאות רבות, אותן לא אביא בכתבה זו. במקום זאת, אסכם בקצרה את הסיבות בעד עדכון המחשבים.
- המערכת לעולם איננה סגורה. גם אם רשת הייצור מבודדת מהאינטרנט ומהרשת המנהלתית, וגם אם המערכת כוללת בתוכה רק מספר קטן של התקנים, יש עדיין גורמים רבים איתם המערכת משתפת פעולה באופן ישיר (על ידי שיתוף מידע בין מחשבי ייצור לבין מערכת ERP, למשל) ובאופן עקיף (למשל, שינוי חוקי מדינה בדוגמת שעון הקיץ שלנו)
- אבטחת מידע זה חשוב. לפי מחקר שנעשה על ידי מכון SANS בשנת 2009, הגורם העיקרי לפריצות אבטחת מידע הינו חוסר עדכונים של תוכנה. ניתן להבין זאת די בקלות - ברגע שחברת תוכנה מכריזה על עדכון קריטי שפותר בעיית אבטחה כלשהי, היא בעצם מודיעה באופן רשמי על מיקום של חור האבטחה, ועל ידי כך מקלה על עבודת ההאקר, שיודע בדיוק היכן ניתן לתקוף את המערכות עליהן לא הוחל העדכון. לכן, התקנת העדכונים הקריטיים מגנה על המערכת.
- שיפור ביציעום ויציבות. לעיתים קרובות, חברות תוכנה מפיצות עדכונים הפותרים בעיות שהתגלו ביישומים כבר לאחר הפצתם. עדכונים מסו זה, בדרך כלל, מתרכזים בשני סוגים של בעיות במוצר: בעיות הקשורות ליציבות התוכנה (מסכים כחולים או תקלות אחרות) וכן בביצועי המערכות. במפעל של אחד מהלקוחות שלי מותקנת מערכת מבוססת בסיס נתונים Microsoft SQL Server 2008. לאחר החלה של חבילת עדכונים 1 (SP1) לתוכנה, ביצועי היישום עלו ב-600 אחוזים, ללא שום שינוי נוסף.
- עדיף לבוא מוכנים. יהיו מצבים, בהם תצטרכו לבצע עדכון כזה או אחר של מערכת - בין אם התקנת גרסה חדשה של יישום תפעולי, או מסיבה אחרת כלשהי. עדיף לבצע את השינוי באופן מבוקר, בזמן וקצב הנוחים לכם, מאשר להיתקל בקשיים בשעה הכי לא רצויה
- לפעמים תיאלצו לעשות עדכון. מדי פעם יהיו מצבים בהם תיאצו לבצע עדכונים למערכת ההפעלה או ליישומים, למשל לצורך התקנה של תוכנת גיבוי. אלא שעדכונים מסויימים דורשים נוכחות של עדכונים קודמים, ולכן שינוי קטן לכאורה עלול לדרוש שינוי מהותי במערכת. וכמו שאמרתי קודם, עדיף להיות מוכנים.
לפי מחקר אחר, שנעשה בארץ מטעם הרשות הלאומית לאבטחת מידע (רא"מ), הוכח באופן חד-משמעי, כי החלת העדכונים הקריטיים, למרות כל הסיכונים והסיבוכים הטמונים בה, מהווה צעד חיוני לאבטחה של מערכות קריטיות. כבר היום, בכל הארגונים המהווים תשתיות קריטיות (כגון מערכות אספקת חשמל ומים, מערכי תקשורת וארגונים שעובדים עם חומרים מסוכנים), חלה חובה של עדכון מערכות מחשב באופן שוטף.
המשימה של הפצת העדכונים, על כל בעיותיה שהוזכרו בתחילת המאמר, מהווה נדבח חשוב להבטחת הפעילות התקינה של המערכות המפעליות לאורך זמן. אם כן, מה עושים על מנת לצמצם את הנזק העלול להיגרם כתוצאה מהחלה לא מבוקרת של עדכונים?
- לפני החלת עדכון זה או אחר, חובה לקרוא את המידע המסופק יל ידי יצרן התוכנה בדבר מהות השינוי, תופעות לוואי אפשריות וורשימת בעייות ידועות. דבר זה בדרך כלל יעזור לכם מראש לאתר את הסיכונים בהחלת העדכון, ולכוון את הבדיקות שתבצעו אחרי העדכון למקום הנכון
- לפני כל שינוי למערכת, יש לבצע גיבוי מלא שלה. במקרה זה, גם אם משהו הלך לא כשורה, תמיד תהיה יכולת לחזור למצב הקודם. אסור להתנהג בפזיזות ולקחת סיכונים לא נחוצים.
- רצוי לבצע בדיקות מעבדה מקיפות לפני החלת העדכון בייצור, על מערכת דומה ככל האפשר למערכת הנמצאת בעבודה. יתרה מכך, לאחר החלת העדכונים והפעלת המערכת מחדש, יש צורך לבצע בדיקות נוספות, על מנת לוודא כי הפונקציונאליות של המערכת לא נפגמה
- את הגיבוי של המערכת יש לשמור לתקופת זמן ארוכה, לא פחות ממספר שבועות, לצורך שחזור המערכת מהגיבוי במקרה של מציאת תקלה שלא אותרה בשלב בדיקות ראשוני.
- לרוב, מומלץ לבצע את החלה מרוכזת של עדכונים מדי תקופה של 2-4 חודשים, בכדי לא להעיק יותר מדי על צוות ה-IT. יחד עם זאת, עדכונים קריטיים מסויימים מומלץ להתקין באופן מיידי. במקרים מסויימים, עליהם בדרך כלל תשמעו בחדשות, יש להחל עדכון מסויים באופו מיידי. אבל גם במקרה זה, מומלץ לבצע סט בדיקות מינימלי על מערכת מקבילה.
- את העדכונים יש להתקין בצורה מבוקרת, באמצעות כלים כמו WSUS או SCCM. דבר זה יאפשר שליטה מרכזית על עדכון המערכות, וימנע את הצורך של מתן גישה ישירה לאינטרנט לתחנות העבודה.
- במערכות שרידות גבוהה מומלץ לבצע את העדכונים בצורה טורית (רק על מכונה אחת בכל פעם) ולא בצורה מקבילה. כך, יהיה קל יותר לבצע גלגול לאחור (rollback) למערכת במקרה הצורך
- אין צורך בהתקנה של כלל העדכונים שקיימים למערכת, אך חובה להתקין את כל העדכונים המסווגים תחת בעיות אבטחה או עדכונים קריטיים אחרים.
- יש לבטל את האיתחול האוטומטי של מחשבים לאחר החלת העדכונים, על מנת למנוע מצב בו המחשב יאתחל את עצמו מחדש ללא השגחה ועל ידי כך יגרום לתקלה רצינית בקו הייצור. יחד עם זאת, יש לבצע אתחול מחדש סמוך ככל האפשר למועד החלת העדכונים.
שימוש קבוע בעקרונות אלו יבטיח, כי המערכות הממוחשבות ישרתו אתכם שנים רבות, במינימום תקלות, ובמינימום כאב ראש.