מתי ואיפה כדאי להשקיע בביצועים בפרויקט התוכנה שלכם?

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

Fail Whale. מקור: טוויטר

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

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

אם נוסיף על כך את נטיית השיווק לשלב מאפייני Social באתרים ולייצר קמפיינים משולבי Offline ו-Online, אנחנו יכולים לגלות שגם האתר התמים של אתמול, הופך לפוטנציאל עבור בעיות ביצועים. והרי אף אחד מאיתנו לא רוצה להגיע לעמוד הראשון בעיתון Ynet ,TheMarker או BizPortal, לפחות לא בנסיבות הללו.

אז מה עושים?

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

מתי לא מתעסקים בביצועים?

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

איך מוודאים צורך עסקי בלי להתבזות?

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

בטא. אתר בטא.

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

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

יש! יש לנו צורך עסקי. מה עושים?

קודם כל מזל טוב!

הבשורה הרעה היא שעכשיו הגעתם לחלק הקשה: צריך להתחיל לקחת החלטות ולבחור באחת משתי הדרכים הקיימות: לזרוק את הקוד הקיים ולכתוב הכל מחדש או, לשנות בשלבים את הקוד הקיים (Refactoring) עד להגעה למטרה.

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

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

עדיין חושבים שזה בלתי אפשרי? אינסטגרם עשו זה ב – 160 קמ”ש…
Mike Krieger, Instagram at the Airbnb tech talk, on Scaling Instagram

החלטנו. אז איך מטפלים בבעיות הביצועים?

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

  1. מהם רכיבי המערכת? בארכיטקטורה העתידית שנבחר, גם אם נפתח מחדש וגם אם נבצע Refactoring, רצוי שנגיע לתצורה שבה רכיבי המערכת מופרדים וחסרי תלות. בצורה כזו ניתן יהיה לשלוף ולהחליף אותם במקרה הצורך (מישהו אמר SOA בקהל?).
  2. מהם התהליכים העסקיים במערכת ומה רמת אינטסיביות השימוש בכל אחד מהם? ברב המערכות ישנם תהליכים עסקיים המתרחשים פעמים ספורות וכאלו שאחראים ל-99 אחוזים מהפעולות במערכת. לדוגמה, במערכת לניהול משכנתאות, פתיחת תיק משכנתא מתבצעת פעם אחת ואילו הגבייה מתבצעת מדי חודש בחודשו. מניסיוני, ההתפלגות קיצונית בהרבה מפארטו (80/20).

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

יש לנו תוכנית ויש לנו אסטרטגיה. אבל איפה אנחנו?

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

  1. זיהוי והגדרת הסף הקריטי לכל רכיב במערכת: הדרך הטובה ביותר היא בניית בדיקת עומסים לכל רכיב קריטי, שתוודא לפני מסירה של כל גרסה שהרכיב יכול להתמודד עם העומסים הרלוונטים. אזהרה! אם המערכת לא מורכבת מסדרה של רכיבים בדידים, היכולת לבצע בדיקת עומסים אפקטיבית היא כמעט ובלתי אפשרית. אם אין לכם אפשרות לבנות בדיקת עומסים אפקטיבית, תדרשו לנטר בזהירות את צריכת המשאבים של המערכת ולזהות מאפיינים כמו תעבורת רשת, צריכת I/O,CPU וזיכרון – ולזהות מתאם ביניהם לבין הפעילות במערכת. לדוגמה, אם כל משתמש מחייב 0.5MB RAM, כנראה ששרת של 2GB יוכל לתמוך לכל היותר ב-4,000 משתמשים.
  2. שילוב מערכת ניטור והתראה: מערכת זו תמדוד את צריכת משאבי המערכת שתוארו קודם ואת התהליכים הקריטיים, כדוגמת מספר העסקאות בשנייה ותתן התראה כאשר נתקרב אל הסף. אל דאגה, אין צורך בפיתוח מערכת ניטור משלכם או החזקה של מספר מערכות ניטור. כל מה שתדרשו הוא לקרוא את ה-API של מערכת הניטור שבה אתם משתמשים ולחשוף את הנתונים בצורה מתאימה.

בשורה התחתונה

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

עשיתם את זה? שברתם את מחסום הביצועים? ישמתם מערכת ניטור שאפשרה לכם לזהות ולהתגבר על הבעיות הקרבות? רוצים לשתף אותנו? אתם יותר ממוזמנים…

הפוסט פורסם במקור בבלוג הפתוח למנהל הפיתוח

משה קפלן

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

הגב

4 תגובות על "מתי ואיפה כדאי להשקיע בביצועים בפרויקט התוכנה שלכם?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
אלקס
Guest

האם אתה יכול לתת דוגמאות למערכות ניטור שכאלה?

משה קפלן
Guest

הי אלקס,

בפוסט קודם נתתי דוגמה יפה למערכת ניטור מעין זו: http://blogs.microsoft.co.il/blogs/vprnd/archive/2011/12/31/5-continuous-deployment.aspx

יש לא מעט מוצרים גם מסחריים וגם Open Source לניטור וגרפים. שלוש המשפחות הכי פופולאריות לניטור מהסוג השני הן: CACTI (דוחות), Nagios (והמחליפים שלו) ו – Zabbix.

ממשיכים לפתח,
משה קפלן

מערכות ניטור
Guest

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

משה קפלן
Guest

התוכן נכון, אני רק יכול לקוות שזה לא SEO…

ממשיכים לפתח,
משה קפלן

wpDiscuz

תגיות לכתבה: