בקרת איכות ידנית היא שורש כל רע

ראשית עלינו להבדיל בין בקרת איכות - QA, לבדיקות קבלה (Acceptance Test). 

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

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

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

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

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

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

מצגת על פריסה ממשכת

בביקורי האחרון בישראל זכיתי להתארח במעבדות המחקר של יבמ, Outbrain וAnswers.com. בביקור הצגתי את עקרונות הפריסה הממשכת והמימוש בקצ'ינג בעזרת מצגת Prezi.

Continuous Deployment on Prezi

ארבעה שלבים חיוניים בראיון עבודה למשרת תכנה

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

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

ראיינתי מאות מהנדסים לחברות בכול הגדלים, להלן המתכון המנצח:

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

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

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

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

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

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

אם הראיון הראשון היה רע במיוחד או השניים הראשונים בינוניים - לחתוך.

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

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

הרצאה על פריסה ממשכת ביבמ חיפה

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

המצגת תפורסם בבלוג בעוד מספר ימים.

תזרום אחי, תזרום

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

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

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

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

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

פריסת אשכולות בגן חיות

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

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

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

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

קו ההגנה לעולם יפרץ - על בדיקות, ניטור, ומערכות חיסוניות

בדיקות יחידה [Unit Testing], ניתוח קוד סטטי [Static analysis], בדיקות שילוב [Integration Tests], ניטור טכני [Monitoring] וניטור עסקי [KPI - Key Performance Indicators] - כולם הם קווי הגנה חיוניים המיועדים להגן על איכות המוצר אל מול הלקוחות.

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

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

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

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

פריסה לעומת השקה

ברוב חברות האינטרנט אין הבדל משמעותי בין פריסה [deployment] להשקה [release], דבר המקשה על הטמעת הפריסה הממשכת [continuous deployment].

קוד מקור [source code] לא פרוש משול למלאי היושב במחסן ומחכה לשיווק. תחזוק המלאי עולה כסף רב, ככל שהמלאי גדול יותר מחזור החיים של המוצר מתארך.

קוד פרוש משול למוצר המונח על המדף וזמין ללקוחות. אמנם לא כל מוצר או תכונה [feature] בשלה מספיק על מנת להיות זמינה בפני הלקוח מיומה הראשון, לשם כך מציגים תכונות אלה בפני לקוחות מעטים בלבד כגון מנהלי המוצר [product managers] בחברה. מנגנון התצוגה החלקית קיים בכל מקרה עבור בדיקות פילוח שוק [A/B testing].
בעוד שפריסה הנה ארוע הנדסי, השקה הנה ארוע עסקי שבתהליכו מרימים את הלוט מעל המוצר. תהליך הנדסי טוב הוא תהליך המבטל את התלות בין האירועים.

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