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