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

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

עד שאתה מגיע לוידאו הבא ((דרך האתר של קאר עצמו)):

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

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

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

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

1. אולי הגיע הזמן לסרט….

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

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

• התחברות למחשב בעבודה מהבית: על ידי התקנת תכנה כמו pcAnywhere אן VNC על המחשב השולחני והמרוחק. שיטה זו דורשת הגדרות ברמת ה-Firewall בחברה ושימוש בתקשורת מאובטחת.
• התחברות לשרת ישומים דרך ערוץ מאובטח. שרתי מסופים פופולרים אצל מנהלי IT¹, היות ומרבית השליטה נשארת אצל מנהל המערכת.
• התחברות דרך צד שלישי: ישנן מספר תכנות (או שרותים) מצד שלישי המאפשרים לשני מחשבים לתקשר אחד עם השני ללא צורך בהגדרות על ה-Firewall. רשימה חלקית ניתן לראות כאן.
• העברת ישומים או מידע למערכות מבוססות Web: מערכות אלו² יכולים להיות מותקנים בתווך בין הרשת הארגונים לרשת האינטרנט, או אצל ספקים חיצוניים, ונגישים באותה מידה מתוך או מחוץ לרשת.

בכל מסלול שיבחר יש לבחון מאיזה מחשב חיצוני נוצר הקשר:

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

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

1. ופחות אצל המשתמשים
2. כגון ניהול מסמכים או אפילו ישומים משרדיים
3. של בן משפחה למשל

לשרות האיכסון של אמזון יש שרות נוסף: העברת מידע על מדיה מגנטית.

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

1. עדכון של פרוטוקול קודם מהראשון באפריל 1990

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

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

הנפילה הקודמת של PayPal הייתה בשנת 2005 ונמשכה 5 ימים. בשביל לסבר את האוזן. 5 ימי כשל בשנה הם 99% זמינות. 5 שעות כשל הם למעלה מ-99.99% זמינות.

האם שרת דואר ארגוני אמין יותר או זמין יותר? שאלה פתוחה.

מחשוב עננים (cloud computing), אינו חדש, אך תופס תאוצה (והייפ). והסיבות אינן רק טכנולוגיות, אלא יותר עסקיות וכלכליות. המחשבה המנחה: טכנולוגיה הופכת למוצר צריכה, והגיוני יותר לרכוש אותה כמו כל מוצר צריכה או שרות אחר, יתר על כן, חברות אינן רואות את מערכות המידע כמעניקות ערך מוסף לארגון.
מאידך, ישנה רתיעה מהוצאת מערכות המידע מהארגון. לעיתים מתוך חשדנות במוטיבציות של הספקים, לעיתים מתוך דאגה לרמת אבטחת המידע ולעיתים מתוך דאגה על ביצועים.
יתר על כן, תמחור מחשוב העננים עדיין לא מאפשר השוואה מובהקת מספיק לבחון את יתרונותיה או חסרונותיה הכלכליים מול ה-Data center הקלסי.
המודל המתבקש לעתיד הנראה לעין, הוא לפיכך מודל היברידי. והנה דוגמה לכך – מערכת דואר של ארגון בינוני, המפוזר בין מספר אתרים, ואולי גם מספר מדינות.
במודל הקלסי, שרת הדואר הארגוני נמצא במטה הארגון. הסניפים המרוחקים מתחברים דרך קוי תקשורת יעודיים או בתקשורת VPN למרכז. אם הסניף המרוחק גדול במיוחד, יתכן כי יהיה בו שרת משני לטובת המשתמשים של אותו סניף. עובדים מחוץ לאתרי החברה מתחברים באמצעות פורטל Web, קישורי VPN או ניתוב דואר למחשבי כף יד או טלפונים חכמים.
כעת נבחן מספר חלופות של מחשוב עננים:

• שרות יעודי: במקרה של דואר אלקטרוני, ספקי אינטרנט נתנו שרות זה כבר שנים, וספקי דואר יעודיים (Hotmail למשל) התחרו ומתחרים בהם. כיום שרותים אלו כמעט פסו מן העולם. ספקיות האינטרנט מציעות תיבות דואר זעומות ובסיסיות, וספקי הדואר נבלעו בפורטלים (Hotmail הוא חלק ממערכת Microsoft Live) או נעלמו.
• שרותים מאורחים (Co-hosted): כאן אפשרו ספקיות אינטרנט ללקוחות להחזיק שרת דואר יעודי באתר הספק, כאשר נטל האחזקה והשרות של החומרה והתוכנה מתחלקים בצורות שונות בין הספק ללקוח. מודל זה כמעט זהה למודל הקלסי, למעט מיקומם הפיזי של השרתים, בעיקר בעסקים קטנים ובינונים, בהם אין יחידת IT מובנית.
• ענן, או grid: הספק מעניק את תשתית החומרה, התקשורת (ולעיתים גם את מערכת ההפעלה), עליה מתקין הלקוח את מערכת הדואר. דוגמא לכך הוא ה"ענן האלסטי" של אמזון.
• תוכנה כשרות, או SaaS: כאן מקבל הלקוח סביבת עבודה השייכת במלואה לספק ובאחריותו. הדוגמה המובהקת היא שרותי Google Apps, אך גם ספק תכנה קלסי כמו מיקרוסופט מציעה את שרת הדואר שלה כשרות. לעיתים השרות קיים כחלק מסביבת שרותים נוספת, כמו במקרה של השרות לעסקים קטנים של יאהו.

המודלים של ענן או שרות הם המעניינים ביותר, היות ואלו הם המעניקים את הערך המוסף לעסק. במקרה שלנו (דואר אלקטרוני), ניתן לראות את היתרונות הבאים:

• חומרה: אין צורך בחומרה יעודית לשרתים בתוך הארגון.
• עומס תקשורת: ירידה בעומס על התקשורת מחוץ לאתר המרכזי של החברה (מאתרי משנה או ממשתמשים העובדים מבחוץ).
• מורכבות תקשרות: אין צורך בניהול מערכות  VPN

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

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

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

מספר נקודות שיש לבחון מול כל ספק.

• תנאי השרות והזמינות, הידועים בראשי התבות SLA או Service Level Agreement: אלו קובעים את קוי הבסיס לזמינות השרות ומה זמן התגובה לתקלה והקנס לאי עמידה בו.
• יבוא: מה הכלים והאפשרויות של יבוא מידע (המקרה זה דואר קיים) למערכת החדשה
• יצוא: לא פחות חשוב – מה האפשרויות של יצוא המידע במצב של סיום השרות.
• שימור ואיחזור מידע: מה הכלים לשימור מידע, גיבויו (האם ניתן למשל לגבות את הדואר למערכת מקומית?)
• ממשקים: האם קיימים ממשקים למערכות בהם משתמשים בחברה (למשל טלפונים חכמים)

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

ניסיתי למצוא מונח בעברית ל-Scalability. התרגום היחידי שמצאתי הוא הקישור המביך הבא¹.

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

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

צחוק בצד, אחד הטיעונים של אנשי ה-IT היא: "תנו לנו משאבים כמו X, ותקבלו שרות כמו X". גוגל, למשל, מתחייבת לזמינות של 99.9% (חודשית). דהיינו 72 שעות כשל, עדיין מהווה עמידה בתנאים. אני מצליח לשמור על 99.4%. אבל זמינות ועמידה בתנאי שרות אינה מעניינית את המשתמש ברגע שבו הוא זקוק לשרות. לא בכדי מיקור החוץ זוכה לכותרות, הן בשרות והן בפיתוח.

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

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

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

1. ואני לא היחידי שמחפש מונח שכזה
2. ועלי

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

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

גוגל, כמובן, אינו היחיד. יאהו, מיקרוסופט, AOL ואחרים מעניקים שרותים דומים. ישנן חברות הנותנות שרותים יעודיים, כמו SalesForce ,(קשרי לקוחות) Amazon S3 (איכסון שרותים), ואחרים. השרותים היעודיים אינם מיועדים לרב למשתמשי הקצה, אלא לנותני שרותים אחרים. כל השרותים הללו נכללים תחת הזומילה  SaaS, תכנה כשרות,

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

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

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

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

1. או מה שעלול להראות כמשקל עודף בעיני בעלי המניות

לכל אחד דעה ואמירה כל המצב הכלכלי. גם לי.

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

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

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

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

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

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

היום אנו רואים את אלו שנשארו בצד. אנחנו.

1. טפו, טפו, טפו
2. ישירות או דרך קרנות השתלמות וקופות גמל
3. אני רוצה לישון בלילה

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

למה לא?

יש לנו תכנה שפותחה על ידי צוות פנימי. בכדי לעבוד:

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

מי צריך וירוסים ורוגלות מבחוץ כשיש מפתחים מבית.

אילן שביט תוהה האם תכנה פתוחה¹ היא בטוחה יותר יותר או מתכנה קניינית.

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

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

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

• קבוצות דיון או רשימות תפוצה גלויות הדנות בתכנה
• ניהול באגים  גלוי לקהל הרחב
• גילוי נאות

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

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

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

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