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

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

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

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

חודש לפני

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

אסטרטגיות הוראה היא מובילת שוק בתוכניות לימודים לילדים צעירים מאוד מגיל לידה ועד גיל שלוש. חברת "הנייר" המסורתית כבר בת 40 וגרסת ה-SaaS הדיגיטלית של הפלטפורמה היא בת 10. לאחרונה יחסית החל תהליך התאמת הטכנולוגיה הדיגיטלית לסטנדרטים של החברה. הגרסה ה"חדשה" הושקה ב-2017 והייתה כמעט כמו הישנה, ​​רק שהיא עבדה יותר גרוע.

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

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

לפלטפורמה, שנראתה רק בת שנתיים, הייתה ערימה מוזרה: ColdFusion ו-SQL Server מ-2. ColdFusion, אם אתה לא יודע, וסביר להניח שאתה לא יודע, הוא PHP ארגוני שיצא באמצע שנות ה-2008, ומאז אפילו לא שמעתי עליו. היו גם: Ruby, MySQL, PostgreSQL, Java, Go, Python. אבל המונוליט הראשי רץ על ColdFusion ו-SQL Server.

בעיות

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

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

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

יומיים לפני

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

אם לשפוט לפי הגרף, ברור שמשהו קרה, ולא ברור מה. התברר שהבעיה הייתה חביון רשת במרכז הנתונים: 5 MS השהייה במרכז הנתונים הפך ל-2 שניות למשתמשים. לא ידעתי למה זה קרה, אבל בכל מקרה נודע שהבעיה היא במרכז הנתונים.

ביום הראשון

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

במשך יומיים, דפי המשתמשים נטענו בממוצע תוך 4 שניות. אני שואל אם מצאו מה הבעיה.

- כן, פתחנו כרטיס.
- ו?
- ובכן, הם עדיין לא ענו לנו.

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

יש ציטוט טוב שמתאים מאוד לזה:

"לפעמים כדי לשנות טכנולוגיה אתה צריך לשנות את הארגון."

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

יום שלישי

אז, הטעינה נמשכת 4 שניות, ומ-13 עד 15 הפסגות הגדולות ביותר.

ביום השלישי במהלך פרק זמן זה, מהירות ההורדה נראתה כך:

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

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

אבל אסור לנו לשכוח שלפני שאתה מקבל את התשובה הנכונה, אתה צריך לשאול את השאלה הנכונה. השאלה הבאה שלי הייתה: כמה שרתי חזית יש לנו? התשובה "קצת בלבלה אותי" - היו לנו 17 שרתי חזית!

- אני נבוך לשאול, אבל 150 חלקי 17 נותן בערך 8? אתה אומר שכל שרת מאפשר 8 בקשות בשנייה, ואם מחר יהיו 160 בקשות בשנייה, נצטרך עוד 2 שרתים?

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

var currentClass = classes.getCurrentClass();
return currentClass;

הייתה פונקציה getCurrentClass(), כי הכל באתר עובד בהקשר של מחלקה - זה נכון. ולפונקציה האחת הזו בכל עמוד היו 200+ בקשות.

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

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

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

אבל פתרון הבעיה הראשונה הזו הוריד את הגרף הרבה יותר נמוך.

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

יום עשירי

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

שוב התגלה משהו מעניין. הצוות כלל: 18 מפתחים; 8 בודקים; 3 מנהלים; 2 אדריכלים. וכולם השתתפו בטקסים משותפים, כלומר, יותר מ-30 איש הגיעו לסטנד אפ מדי בוקר וסיפרו מה הם עשו. ברור שהפגישה לא ארכה 5 או 15 דקות. אף אחד לא הקשיב לאף אחד כי כולם עובדים על מערכות שונות. בצורה זו, 2-3 כרטיסים לשעה לפגישת טיפוח כבר היו תוצאה טובה.

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

כתוצאה מכך קיבלנו:

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

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

יום אחד עשרה

בתהליך של שינוי מבנה הצוות גיליתי איך לספור סיפורנקודות . 1 SP היה שווה ליום אחד, וכל כרטיס הכיל SP גם לפיתוח וגם ל-QA, כלומר לפחות 2 SP.

איך גיליתי את זה?

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

אחרי זה אנחנו:

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

היום העשרים

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

מטרות לטווח ארוך:

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

בעבר נאמר לעתים קרובות: "בואו נשכתב הכל ב[שפה/מסגרת], הכל יעבוד טוב יותר!"

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

• משקף את הייעוד והמטרות של הפרויקט;
• נותן עדיפות למטרות עיקריות;
• מכיל לוח זמנים להשגתן.

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

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

לדוגמה, אחד ה-KPIs הארגוניים הוא הגדלת נתח שוק באמצעות מוצרים חדשים.

איך אתה יכול לתמוך במטרה לקבל יותר מוצרים חדשים?

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

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

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

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

יום שלושים

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

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

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

ברור כמה היינו רחוקים מ-n-1 אם הפלטפורמה הייתה מבוססת על ColdFusion ו-SQL Server 2008, שלא נתמך עוד ביולי.

יום ארבעים וחמש

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

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

כשעשיתי את זה, שני דברים משכו את עיני:

• אחוז גבוה של כרטיסים שהוחזרו מ-QA בחזרה למפתחים;
• בדיקת בקשת המשיכה ארכה יותר מדי זמן.

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

"אתה לא יכול לשפר את מה שאתה לא יכול למדוד."

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

כדי למדוד זאת, הוספנו כמה שלבים לתהליך Jira: "מוכן לפיתוח" ו"מוכן ל-QA" כדי למדוד כמה זמן כל כרטיס ממתין וכמה פעמים הוא חוזר לשלב מסוים.

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

• יעילות תהליך: ביצוע ומתוכנן/נמסר.
• איכות תהליך: מספר פגמים, פגמים מ-QA.

זה באמת עוזר להבין מה הולך טוב ומה לא הולך טוב.

יום החמישים

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

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

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

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

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

יום חמישים ואחד

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

"רוב הבעיות הן בעיות של אנשים."

גיליתי שלצוות ככזה - גם Dev וגם Ops - יש שלוש בעיות גדולות:

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

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

אבל אתה לא יכול להשתפר בלי לשנות שום דבר.

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

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

• טעינה של 12 שניות;
• 5-10 דקות השבתה בכל שחרור;
• פתרון בעיות קריטיות לוקח ימים ושבועות;
• חוסר בכוח אדם 24/7 / כוננות.

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

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

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

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

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

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

בתגובה, הצגתי את הפרקטיקות הבאות:

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

יום השישים

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

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

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

תוצאות מלאי:

• עזבנו את אותו מרכז נתונים.
• ביטלנו את החוזה עם 3 שירותי יומן. בגלל שהיו לנו 5 כאלה - כל מפתח שהתחיל לשחק עם משהו לקח אחד חדש.
• 7 מערכות AWS הושבתו. שוב, אף אחד לא עצר את הפרויקטים המתים; כולם המשיכו לעבוד.
• עלויות תוכנה מופחתות פי 6.

יום שבעים וחמישה

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

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

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

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

כלומר, ColdFusion עוברת דרך Jetty ו-nginx ומשיקה את הדפים. ותמונות, JS ו-CSS עוברות nginx נפרד עם תצורות משלהן. זה נוהג די סטנדרטי שאני מדבר עליו כתבתי לפני כמה שנים. כתוצאה מכך, תמונות נטענות הרבה יותר מהר, ו...מהירות הטעינה הממוצעת עלתה ב-200 אלפיות השנייה.

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

יום שמונים וחמישה

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

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

מסקנה

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

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

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

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

עם זה כל השאר יבוא.

ליאון אש בטוויטר, facebook ו - בינוני.

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

מקור: www.habr.com