פיתוח בפייסבוק

26 בפברואר 2011

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

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

 

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



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


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


  3. Crowd Sourcing: למי שזוכר כיצד פייסבוק הפכה לרב לשונית, לא צריך הסברים נוספים.

 

קשה באימונים קל בקרב

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

 

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

 

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

 

איך מכשירים (או יוצרים תרבות ארגונית)?
הבנו שתהליך הגיוס הוא שלב ראשון בבניית התרבות הארגונית. השלב השני הוא ההכשרה: בגוגל שולחים אותך ללא נודע ומכניסים אותך לתרבות הארגונית ע"י ביצוע Code Review אינטנסיבי לכל שורת קוד שכתבת. בפייסבוק מסע החניכה מבוצע ע"י טירונות, שנמשכת ארבע עד ששה שבועות. טירונות זאת כוללת הרצאות וטרטורים בדמות פתרון באגים במערכות החברה. במהלך הטירונות כ – 10% מהמשתתפים נושרים, ואילו הנותרים מקבלים כומתה…. סליחה… הרשאות לבסיס הנתונים האמיתי…
השלב השלישי הוא שמירה על שקיפות: גם בגוגל וגם בפייסבוק כל מהנדס יכול לגעת בכל חתיכת קוד במערכת ולבצע Check In. התרבות הזאת קיימת גם בחברות אחרות דוגמת Red Hat. בכל מקרה, כל שורה עוברת Code Review.
השלב הרביעי הוא Dogfooding: כמו בגוגל גם בפייסבוק עושים שימוש אגרסיבי בכלי הזה. עובדי החברה עובדים תמיד על גרסה שמקדימה בשעה עד שתיים עשרה שעות את הגרסה שזמינה למשתמשים החיצוניים.

 

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



  1. P1: המערכת הפנימית שבה עושים שימוש עובדי החברה ומשמשת ל – Dogfooding. שלב זה כולל העלאה ל – 6 שרתים בלבד.


  2. P2: העלאה מצומצמת חיצונית.


  3. P3: העלאה מלאה.

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

 

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



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


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

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



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


  2. רק המשתתפים בתהליך יגדירו את התהליך, ולא גורמים חיצוניים לו.


  3. יש לשמור את הנוהל פשוט ככל האפשר ולא להוסיף שלבים לא הכרחיים.

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

 

נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!

 

ממשיכים לפתח,
משה קפלן Follow MosheKaplan on Twitter

 

נ.ב בימים אלו אני מתחיל בהרפתקאה חדשה. בינתיים אם אתם מעוניינים בייעוץ על ארכיטקטורה של מערכות אינטרנט וענן, יישום של מענה Scaleout, ייעוץ ניהולי או עזרה בהאצת הביצועים של המערכת, אתם יותר ממוזמנים לפנות: mokplan[at]gmail[dot]com.

 

השאלה של קארן שליין:

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

 

תשובה:

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



  1. Dogfooding: העובדים של פייסבוק משתמשים באתר (בד"כ בגרסה שמקדימה את הגרסה בייצור במספר שעות) וככה "אוכלים את הדיסה שהם בישלו.


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


  3. בדיקה יזומה של התהליך ע"י המתכנת/איש אוטומציה. הבדיקה מבוצעת ע"י אוטומציה בד"כ.

הערה שהגיעה מניוזגיק: כתבת כאן רשימה ארוכה של נהלים, ואתה מסכם ב"אין נהלים". אתה לא מרגיש שזו סתם סיסמא?


תשובה:
אומרים שיש שאלות טובות ושאלות מצויינות. שלך ללא ספק נופלת בחלק של המצויינות.
השאלה הגדולה האם הנוהל הוא בהגדרתו נוהל שתלוי על הקיר או נמצא בתוך קלסר ה – ISO שלכם ואף אחד לא טורח להציץ חוץ מהשבוע לפני בחינת ה – ISO, או שהוא דבר חי שעובר "מאב לבן".
בפייסבוק הנוהל חי, הוא לא נרשם אלא אם יש קטסטרופה, והוא למעשה עובר בתוך הטירונות ולאחר מכן במהלך העבודה… זה די דומה לנוהל שלך בבוקר, אתה קם, מצחצח שיניים, אוכל או לא ארוחת בוקר, שם בושם או סתם זורק חולצה ורץ החוצה לעבודה או ללקוח. אף פעם לא תעדת את זה והתיחסת לזה כנוהל, אבל הוא שם.
אם צריך לשנות והחלטת שאתה רוצה להתגלח הבוקר, אתה לא צריך ללכת לאשר את הנוהל אצל אף אחד (אשתך או החברה אולי יטענו ההיפך), אתה פשוט משנה אותו כדי להתאים אותו לחיים הדינאמיים.
אותו דבר בפיסבוק, במקום לכתוב נהלים, לקבל 20 חתימות ואחרי שבוע לגלות שאין לזה קשר למציאות, הנוהל שבע"פ משתנה לפי הצורך…


 


הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

6 תגובות

  1. Rotem Bloom1 במרץ 2011 ב 16:22

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

    בהצלחה בדרך החדשה
    רותם

    הגב
  2. Moshe Kaplan1 במרץ 2011 ב 17:48

    תודה X2 רותם,

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

    הגב
  3. עופר10 במרץ 2011 ב 8:54

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

    הגב
  4. Moshe Kaplan10 במרץ 2011 ב 10:49

    עופר,

    תודה רבה,
    תגובה כזאת מעודדת את יציאת הפוסט הבא 🙂

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

    הגב
  5. ניר אורן27 באפריל 2011 ב 23:06

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

    הגב
  6. Moshe Kaplan27 באפריל 2011 ב 23:49

    שלום ניר,

    קודם כל תודה,

    לגבי התקלות אני מסכים, לא הכל מושלם. שמעתי טענות מאנשים פנימיים בגוגל למשל (זה לא פייסבוק, אבל כאמור 30% מהמהנדסים שלהם מגיעים משם) בכל רגע נתון 10% מ – Features תקולים!
    מצד שני עם יד על הלב, אצל האחרים המצב יותר טוב?

    ועכשיו ברצינות, ההמלצה הכי טובה שלי בנושא הזה היא להטמיע כלי מעורבות משתמשים כדוגמת Kampyle, GetSatisfaction או UserVoice. זה עולה, אבל זה מאפשר למשתמשים שלך בלחיצת כפתור להודיע לך איפה הבעיות (וזה הרבה יותר זול מ – QA).

    נ.ב העפתי מבט באתר שלך, הרעיון מדליק. איך עשית את הסרטון? עם http://www.fiverr.com?

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

    הגב