เป็นที่ทราบกันดีว่าความสามารถของ CTO จะได้รับการทดสอบเฉพาะครั้งที่สองที่เขาปฏิบัติหน้าที่นี้ เพราะการทำงานในบริษัทหลายปี พัฒนาไปพร้อมกับมันเป็นเรื่องหนึ่ง และการอยู่ในบริบททางวัฒนธรรมเดียวกัน ก็ค่อยๆ ได้รับความรับผิดชอบมากขึ้น และมันก็เป็นอีกเรื่องหนึ่งที่เข้ามารับตำแหน่งผู้อำนวยการฝ่ายเทคนิคของบริษัทที่มีปัญหาเดิมๆ และปัญหามากมายที่ซุกซ่อนไว้ใต้พรม

ในแง่นี้ประสบการณ์ของลีออน ไฟร์ ที่เขาเล่าให้ฟัง DevOpsConfแม้จะไม่ได้มีเอกลักษณ์เฉพาะตัวเลย แต่เมื่อคูณด้วยประสบการณ์ของเขาและจำนวนบทบาทต่างๆ ที่เขาพยายามทำมาตลอดระยะเวลา 20 ปี นับว่ามีประโยชน์มาก ด้านล่างเป็นลำดับเหตุการณ์ตลอด 90 วัน และเรื่องราวมากมายที่น่าหัวเราะเมื่อเกิดขึ้นกับคนอื่น แต่ไม่สนุกเมื่อเผชิญหน้ากัน

ลีออนพูดภาษารัสเซียได้ไพเราะมาก ดังนั้นหากคุณมีเวลา 35-40 นาที ฉันขอแนะนำให้ดูวิดีโอ เวอร์ชันข้อความเพื่อประหยัดเวลาด้านล่าง

รายงานเวอร์ชันแรกเป็นคำอธิบายที่มีโครงสร้างอย่างดีเกี่ยวกับการทำงานร่วมกับบุคลากรและกระบวนการต่างๆ โดยมีคำแนะนำที่เป็นประโยชน์ แต่เธอไม่ได้ถ่ายทอดความประหลาดใจทั้งหมดที่พบระหว่างทาง ดังนั้นฉันจึงเปลี่ยนรูปแบบและนำเสนอปัญหาที่เกิดขึ้นตรงหน้าฉันเหมือนกล่องในบริษัทใหม่ และวิธีการแก้ไขตามลำดับเวลา

หนึ่งเดือนก่อน

เช่นเดียวกับเรื่องราวดีๆ หลายๆ เรื่อง เรื่องนี้เริ่มต้นด้วยแอลกอฮอล์ เรากำลังนั่งอยู่กับเพื่อนในบาร์ และตามที่คาดไว้ในหมู่ผู้เชี่ยวชาญด้านไอที ทุกคนต่างร้องไห้เกี่ยวกับปัญหาของตนเอง หนึ่งในนั้นเพิ่งเปลี่ยนงานและกำลังพูดถึงปัญหาของเขากับเทคโนโลยี กับผู้คน และกับทีม ยิ่งฉันฟังมากเท่าไร ฉันก็ยิ่งตระหนักว่าเขาควรจะจ้างฉัน เพราะนี่คือปัญหาประเภทต่างๆ ที่ฉันแก้ไขมาตลอด 15 ปีที่ผ่านมา ฉันบอกเขาอย่างนั้น และวันรุ่งขึ้นเราก็พบกันในสภาพแวดล้อมการทำงาน บริษัทนี้มีชื่อว่า Teaching Strategies

Teaching Strategies เป็นผู้นำตลาดในด้านหลักสูตรสำหรับเด็กเล็กตั้งแต่แรกเกิดถึงสามขวบ บริษัท “กระดาษ” แบบดั้งเดิมมีอายุ 40 ปีแล้ว และแพลตฟอร์มเวอร์ชัน SaaS ดิจิทัลมีอายุ 10 ปี เมื่อไม่นานมานี้ กระบวนการปรับเทคโนโลยีดิจิทัลให้เข้ากับมาตรฐานของบริษัทได้เริ่มต้นขึ้น เวอร์ชัน “ใหม่” เปิดตัวในปี 2017 และเกือบจะเหมือนกับเวอร์ชันเก่า เพียงแต่ทำงานได้แย่ลงเท่านั้น

สิ่งที่น่าสนใจที่สุดคือปริมาณการเข้าชมของบริษัทนี้สามารถคาดเดาได้มาก - จากวันต่อวัน ปีต่อปี คุณสามารถคาดการณ์ได้อย่างชัดเจนว่าจะมีคนมากี่คนและเมื่อใด ตัวอย่างเช่น ระหว่าง 13 ถึง 15 น. เด็กทุกคนในโรงเรียนอนุบาลเข้านอนและครูเริ่มป้อนข้อมูล และสิ่งนี้เกิดขึ้นทุกวัน ยกเว้นวันหยุดสุดสัปดาห์ เพราะแทบไม่มีใครทำงานในวันหยุดสุดสัปดาห์

เมื่อมองไปข้างหน้าเล็กน้อย ฉันจะสังเกตว่าฉันเริ่มทำงานในช่วงที่มีการเข้าชมสูงสุดต่อปี ซึ่งน่าสนใจด้วยเหตุผลหลายประการ

แพลตฟอร์มนี้ซึ่งดูเหมือนว่าจะมีอายุเพียง 2 ปี มีสแต็กที่แปลกประหลาด: ColdFusion & SQL Server จากปี 2008 ColdFusion หากคุณไม่รู้ และมีแนวโน้มว่าคุณไม่รู้ นั่นคือ PHP ระดับองค์กรที่เปิดตัวในช่วงกลางทศวรรษที่ 90 และตั้งแต่นั้นมาฉันก็ไม่เคยได้ยินเรื่องนี้เลย นอกจากนี้ยังมี: 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 ทางเทคโนโลยีไม่สอดคล้องกับระดับองค์กร ทุกคนก็จะดึงผ้าห่มมาเอง

ตัวอย่างเช่น หนึ่งใน KPI ขององค์กรคือการเพิ่มส่วนแบ่งการตลาดผ่านผลิตภัณฑ์ใหม่ๆ

คุณจะสนับสนุนเป้าหมายการมีผลิตภัณฑ์ใหม่ๆ มากขึ้นได้อย่างไร?

• ประการแรก เราต้องการใช้เวลามากขึ้นในการพัฒนาผลิตภัณฑ์ใหม่แทนที่จะแก้ไขข้อบกพร่อง นี่เป็นโซลูชันเชิงตรรกะที่วัดได้ง่าย
• ประการที่สอง เราต้องการสนับสนุนปริมาณธุรกรรมที่เพิ่มขึ้น เนื่องจากยิ่งส่วนแบ่งการตลาดมากขึ้น ผู้ใช้ก็จะมากขึ้น และปริมาณการเข้าชมก็จะมากขึ้นตามไปด้วย

จากนั้น KPI แต่ละรายการที่สามารถดำเนินการได้ภายในกลุ่ม ตัวอย่างเช่น จะอยู่ในจุดที่ข้อบกพร่องหลักเกิดขึ้น หากคุณมุ่งเน้นที่ส่วนนี้โดยเฉพาะ คุณจะมั่นใจได้ว่ามีข้อบกพร่องน้อยลงมาก จากนั้นเวลาในการพัฒนาผลิตภัณฑ์ใหม่และอีกครั้งสำหรับการสนับสนุน KPI ขององค์กรก็จะเพิ่มขึ้น

ดังนั้น ทุกการตัดสินใจ รวมถึงการเขียนโค้ดใหม่ จะต้องสนับสนุนเป้าหมายเฉพาะที่บริษัทตั้งไว้สำหรับเรา (การเติบโตขององค์กร คุณสมบัติใหม่ การสรรหาบุคลากร)

ในระหว่างกระบวนการนี้ สิ่งที่น่าสนใจปรากฏให้เห็น ซึ่งกลายเป็นข่าวไม่เพียงแต่สำหรับนักเทคโนโลยีเท่านั้น แต่โดยทั่วไปในบริษัทด้วย: ตั๋วทั้งหมดจะต้องเน้นไปที่ KPI อย่างน้อยหนึ่งรายการ นั่นคือ หากผลิตภัณฑ์บอกว่าต้องการสร้างคุณลักษณะใหม่ ควรถามคำถามแรกว่า "คุณลักษณะนี้สนับสนุน KPI ใด" ถ้าไม่เช่นนั้นก็ขออภัยด้วย - ดูเหมือนว่าเป็นคุณสมบัติที่ไม่จำเป็น

วันที่สามสิบ

เมื่อปลายเดือน ฉันค้นพบความแตกต่างอีกอย่างหนึ่ง นั่นคือไม่มีใครในทีมปฏิบัติการของฉันเคยเห็นสัญญาที่เราทำกับลูกค้าเลย คุณอาจถามว่าทำไมคุณต้องดูผู้ติดต่อ

• ประการแรก เนื่องจาก SLA ระบุไว้ในสัญญา
• ประการที่สอง SLA ทั้งหมดแตกต่างกัน ลูกค้าแต่ละรายมาพร้อมกับความต้องการของตัวเอง และฝ่ายขายก็ลงนามโดยไม่ดู

ความแตกต่างที่น่าสนใจอีกประการหนึ่งคือสัญญากับลูกค้ารายใหญ่รายหนึ่งระบุว่าเวอร์ชันซอฟต์แวร์ทั้งหมดที่รองรับโดยแพลตฟอร์มจะต้องเป็น n-1 นั่นคือไม่ใช่เวอร์ชันล่าสุด แต่เป็นเวอร์ชันสุดท้าย

ชัดเจนว่าเราอยู่ห่างจาก n-1 แค่ไหนหากแพลตฟอร์มนั้นใช้ ColdFusion และ SQL Server 2008 ซึ่งไม่ได้รับการสนับสนุนอีกต่อไปในเดือนกรกฎาคม

วันที่สี่สิบห้า

ประมาณกลางเดือนที่ 2 ฉันก็มีเวลาพอที่จะนั่งทำ ความคุ้มค่ากระแสการทำแผนที่ ได้อย่างครบถ้วนตลอดกระบวนการ เหล่านี้เป็นขั้นตอนที่จำเป็นที่ต้องดำเนินการ ตั้งแต่การสร้างผลิตภัณฑ์ไปจนถึงการส่งมอบให้กับผู้บริโภค และจำเป็นต้องอธิบายรายละเอียดให้มากที่สุดเท่าที่จะเป็นไปได้

คุณแบ่งกระบวนการออกเป็นชิ้นเล็กๆ และดูว่าสิ่งใดใช้เวลานานเกินไป สิ่งใดที่สามารถปรับให้เหมาะสม ปรับปรุงได้ เป็นต้น ตัวอย่างเช่น คำขอผลิตภัณฑ์ต้องใช้เวลานานเท่าใดในขั้นตอนการเตรียมการ คำขอถึงตั๋วที่นักพัฒนาสามารถทำได้เมื่อใด QA เป็นต้น ดังนั้นคุณจึงดูรายละเอียดแต่ละขั้นตอนและคิดถึงสิ่งที่สามารถเพิ่มประสิทธิภาพได้

เมื่อฉันทำสิ่งนี้ มีสองสิ่งที่ดึงดูดสายตาของฉัน:

• เปอร์เซ็นต์ตั๋วที่สูงคืนจาก QA กลับไปยังนักพัฒนา
• การตรวจสอบคำขอดึงข้อมูลใช้เวลานานเกินไป

ปัญหาคือข้อสรุปเหล่านี้ดูเหมือนจะใช้เวลานาน แต่เราไม่แน่ใจว่านานแค่ไหน

"คุณไม่สามารถปรับปรุงสิ่งที่คุณวัดไม่ได้"

จะพิสูจน์ได้อย่างไรว่าปัญหาร้ายแรงแค่ไหน? มันเสียเวลาเป็นวันหรือชั่วโมง?

ในการวัดสิ่งนี้ เราได้เพิ่มขั้นตอนสองสามขั้นตอนในกระบวนการ Jira: “พร้อมสำหรับการพัฒนา” และ “พร้อมสำหรับ QA” เพื่อวัดระยะเวลาที่ตั๋วแต่ละใบรอและกี่ครั้งที่ตั๋วจะกลับสู่ขั้นตอนหนึ่ง

นอกจากนี้ เรายังเพิ่ม "อยู่ระหว่างการตรวจสอบ" เพื่อให้ทราบว่าโดยเฉลี่ยมีตั๋วกี่ใบสำหรับการรีวิว และจากนี้คุณก็สามารถเริ่มเต้นได้เลย เรามีตัวชี้วัดของระบบ ตอนนี้เราได้เพิ่มตัวชี้วัดใหม่และเริ่มวัดผล:

• ประสิทธิภาพของกระบวนการ: ประสิทธิภาพและการวางแผน/ส่งมอบ
• คุณภาพกระบวนการ: จำนวนข้อบกพร่องข้อบกพร่องจาก QA

ช่วยให้เข้าใจได้ว่าอะไรกำลังไปได้ดีและสิ่งไหนไม่ดี

วันที่ห้าสิบ

แน่นอนว่าทั้งหมดนี้เป็นสิ่งที่ดีและน่าสนใจ แต่เมื่อถึงปลายเดือนที่สองมีบางอย่างเกิดขึ้นซึ่งโดยหลักการแล้วสามารถคาดเดาได้แม้ว่าฉันจะไม่ได้คาดหวังขนาดนั้นก็ตาม ผู้คนเริ่มออกไปเพราะผู้บริหารระดับสูงเปลี่ยนไป คนใหม่เข้ามาบริหารและเริ่มเปลี่ยนแปลงทุกอย่าง และคนเก่าก็เลิกไป และโดยปกติแล้วในบริษัทที่มีอายุหลายปี ทุกคนเป็นเพื่อนกันและทุกคนก็รู้จักกัน

สิ่งนี้เป็นสิ่งที่คาดหวัง แต่ขนาดของการเลิกจ้างนั้นไม่คาดคิด ตัวอย่างเช่น ในหนึ่งสัปดาห์ หัวหน้าทีมสองคนยื่นใบลาออกพร้อมๆ กันตามเจตจำนงเสรีของตนเอง ดังนั้นฉันไม่เพียงแต่ต้องลืมปัญหาอื่นๆ เท่านั้น แต่ต้องให้ความสำคัญกับ การสร้างทีม. นี่เป็นปัญหาที่ยาวและยากในการแก้ไข แต่ก็ต้องจัดการเพราะฉันต้องการช่วยเหลือผู้คนที่ยังคงอยู่ (หรือส่วนใหญ่) จำเป็นต้องตอบสนองต่อความจริงที่ว่าผู้คนจากไปเพื่อรักษาขวัญกำลังใจในทีม

ตามทฤษฎีแล้ว นี่เป็นสิ่งที่ดี: มีคนใหม่เข้ามาซึ่งมี carte blanche ครบชุด ซึ่งสามารถประเมินทักษะของทีมและแทนที่บุคลากรได้ ที่จริงแล้ว คุณไม่สามารถดึงดูดผู้คนใหม่ๆ เข้ามาได้ด้วยเหตุผลหลายประการเช่นนี้ จำเป็นต้องมีความสมดุลเสมอ

• เก่าและใหม่ เราต้องรักษาคนเฒ่าที่สามารถเปลี่ยนแปลงและสนับสนุนภารกิจได้ แต่ในขณะเดียวกัน เราจำเป็นต้องนำเลือดใหม่เข้ามา เราจะพูดถึงเรื่องนั้นในภายหลังเล็กน้อย
• ประสบการณ์. ฉันพูดคุยมากมายกับรุ่นน้องดีๆ ที่กระตือรือร้นและอยากร่วมงานกับเรา แต่ฉันไม่สามารถรับพวกเขาได้เพราะมีรุ่นพี่ไม่เพียงพอที่จะสนับสนุนรุ่นน้องและทำหน้าที่เป็นที่ปรึกษาให้พวกเขา จำเป็นต้องรับสมัครระดับสูงก่อน จากนั้นจึงคัดเลือกเฉพาะเยาวชนเท่านั้น
• แครอทและแท่ง

ฉันไม่มีคำตอบที่ดีสำหรับคำถามว่าสมดุลที่เหมาะสมคืออะไร จะรักษามันไว้อย่างไร จะเก็บได้กี่คน และต้องผลักดันมากแค่ไหน นี่เป็นกระบวนการส่วนบุคคลล้วนๆ

วันที่ห้าสิบเอ็ด

ฉันเริ่มมองดูทีมอย่างใกล้ชิดเพื่อทำความเข้าใจว่าฉันมีใคร และฉันก็จำได้อีกครั้ง:

“ปัญหาส่วนใหญ่คือปัญหาผู้คน”

ฉันพบว่าทีมงานทั้ง Dev และ Ops มีปัญหาใหญ่สามประการ:

• ความพอใจกับสถานการณฌในปัจจุบัน
• ขาดความรับผิดชอบ - เพราะไม่มีใครเคยนำผลงานของนักแสดงมามีอิทธิพลต่อธุรกิจ
• กลัวการเปลี่ยนแปลง

การเปลี่ยนแปลงจะนำคุณออกจากเขตความสะดวกสบายของตัวเองเสมอ และยิ่งคนอายุน้อยก็ยิ่งไม่ชอบการเปลี่ยนแปลงเพราะพวกเขาไม่เข้าใจสาเหตุและไม่เข้าใจว่าทำไม คำตอบที่พบบ่อยที่สุดที่ฉันเคยได้ยินคือ "เราไม่เคยทำอย่างนั้น" ยิ่งกว่านั้นมันถึงจุดที่ไร้สาระโดยสิ้นเชิง - การเปลี่ยนแปลงเพียงเล็กน้อยไม่สามารถเกิดขึ้นได้หากไม่มีใครขุ่นเคือง และไม่ว่าการเปลี่ยนแปลงจะส่งผลกระทบต่องานของพวกเขามากแค่ไหน ผู้คนก็พูดว่า: “ไม่ ทำไมล่ะ? สิ่งนี้จะไม่ทำงาน”

แต่คุณไม่สามารถดีขึ้นได้หากไม่เปลี่ยนแปลงอะไรเลย

ฉันมีการสนทนาที่ไร้สาระอย่างยิ่งกับพนักงานคนหนึ่ง ฉันบอกแนวคิดของฉันในการเพิ่มประสิทธิภาพให้เขาฟัง ซึ่งเขาบอกฉันว่า:
- โอ้คุณไม่เห็นสิ่งที่เรามีเมื่อปีที่แล้ว!
- แล้วไงล่ะ?
“ตอนนี้ก็ดีขึ้นกว่าเดิมมาก”
- แล้วมันไม่มีอะไรดีขึ้นเลยเหรอ?
- เพื่ออะไร?

คำถามที่ดี - ทำไม? ราวกับว่าตอนนี้ดีขึ้นกว่าเดิมแล้วทุกอย่างก็ดีพอ สิ่งนี้นำไปสู่การขาดความรับผิดชอบซึ่งเป็นเรื่องปกติในหลักการ อย่างที่บอกไปแล้วว่ากลุ่มเทคนิคอยู่ข้างสนามนิดหน่อย บริษัทเชื่อว่ามันควรจะมีอยู่แต่ ไม่มีใครเคยกำหนดมาตรฐาน. ฝ่ายสนับสนุนด้านเทคนิคไม่เคยเห็น SLA ดังนั้นจึงค่อนข้าง "ยอมรับได้" สำหรับกลุ่ม (และสิ่งนี้ทำให้ฉันประทับใจมากที่สุด):

• โหลด 12 วินาที;
• หยุดทำงาน 5-10 นาทีในแต่ละครั้ง
• การแก้ไขปัญหาสำคัญใช้เวลาหลายวันและหลายสัปดาห์
• ขาดบุคลากรปฏิบัติหน้าที่ตลอด 24x7 / โทร

ไม่เคยมีใครพยายามถามว่าทำไมเราไม่ทำให้ดีกว่านี้ และไม่มีใครเคยตระหนักว่ามันไม่จำเป็นต้องเป็นเช่นนี้

นอกจากนี้ ยังมีปัญหาอีกประการหนึ่งคือ: ขาดประสบการณ์. ผู้อาวุโสจากไป และทีมเยาวชนที่เหลือเติบโตภายใต้ระบอบการปกครองก่อนหน้านี้ และได้รับพิษจากระบอบการปกครองนี้

ยิ่งไปกว่านั้น ผู้คนยังกลัวที่จะล้มเหลวและดูไร้ความสามารถอีกด้วย สิ่งนี้แสดงให้เห็นในความจริงที่ว่าประการแรกพวกเขา ไม่ว่าในกรณีใดก็ตามจะไม่มีการขอความช่วยเหลือ. กี่ครั้งแล้วที่เราคุยกันเป็นกลุ่มและส่วนตัว และฉันก็พูดว่า “ถามคำถามถ้าคุณไม่รู้ว่าจะทำอะไรสักอย่าง” ฉันมั่นใจในตัวเองและรู้ว่าฉันสามารถแก้ไขปัญหาใด ๆ ได้ แต่มันต้องใช้เวลา ดังนั้นถ้าถามคนที่รู้วิธีแก้ได้ภายใน 10 นาทีก็จะถามครับ ยิ่งมีประสบการณ์น้อย ยิ่งกลัวที่จะถาม เพราะคิดว่าจะถูกมองว่าไร้ความสามารถ

ความกลัวในการถามคำถามนี้แสดงออกมาในรูปแบบที่น่าสนใจ ตัวอย่างเช่น คุณถามว่า “คุณเป็นยังไงบ้างกับงานนี้?” “เหลือเวลาอีกสองสามชั่วโมง ฉันเสร็จแล้ว” วันรุ่งขึ้นถามอีกก็ได้คำตอบว่าทุกอย่างปกติดีแต่มีปัญหาอยู่อย่างหนึ่งคงพร้อมสิ้นวันอย่างแน่นอน ผ่านไปอีกวัน และจนกว่าคุณจะถูกตรึงไว้กับกำแพงและถูกบังคับให้คุยกับใครสักคน สิ่งนี้จะดำเนินต่อไป คนต้องการแก้ปัญหาด้วยตัวเองเขาเชื่อว่าถ้าเขาไม่แก้ปัญหาด้วยตัวเองมันจะเป็นความล้มเหลวครั้งใหญ่

นั่นเป็นเหตุผลที่ นักพัฒนาได้ประมาณการที่สูงเกินจริง. มันเป็นเรื่องเล็ก ๆ น้อย ๆ เหมือนกันตอนที่พวกเขากำลังคุยกันเรื่องงานบางอย่างพวกเขาก็ทำให้ฉันประหลาดใจมาก ซึ่งฉันได้รับแจ้งว่าในการประมาณการของนักพัฒนา นักพัฒนารวมเวลาที่ตั๋วจะถูกส่งคืนจาก QA เนื่องจากพวกเขาจะพบข้อผิดพลาดที่นั่น และเวลาที่ PR จะใช้ และเวลาในขณะที่บุคคลที่ควรตรวจสอบ มันจะยุ่ง - นั่นคือทุกอย่าง อะไรก็ตามที่เป็นไปได้

ประการที่สอง คนที่กลัวว่าจะดูไร้ความสามารถ วิเคราะห์มากเกินไป. เมื่อคุณพูดสิ่งที่ต้องทำจริงๆ มันจะเริ่มต้นว่า “ไม่ แล้วถ้าเราคิดถึงเรื่องนี้ที่นี่ล่ะ?” ในแง่นี้บริษัทของเราไม่ได้มีเอกลักษณ์เฉพาะตัวซึ่งเป็นปัญหามาตรฐานสำหรับคนหนุ่มสาว

เพื่อเป็นการตอบสนอง ฉันจึงได้แนะนำแนวปฏิบัติต่อไปนี้:

• กฎ 30 นาที หากคุณไม่สามารถแก้ไขปัญหาได้ภายในครึ่งชั่วโมง ให้ขอให้ใครสักคนช่วย วิธีนี้ใช้ได้ผลในระดับความสำเร็จที่แตกต่างกันไป เพราะผู้คนยังคงไม่ถาม แต่อย่างน้อยกระบวนการก็ได้เริ่มต้นขึ้นแล้ว
• กำจัดทุกสิ่งยกเว้นสาระสำคัญในการประมาณกำหนดเวลาในการดำเนินการให้เสร็จสิ้น ได้แก่ พิจารณาเฉพาะระยะเวลาในการเขียนโค้ดเท่านั้น
• การเรียนรู้อย่างต่อเนื่อง สำหรับผู้ที่วิเคราะห์มากเกินไป มันเป็นเพียงการทำงานอย่างต่อเนื่องกับผู้คน

วันที่หกสิบ

ขณะที่ฉันกำลังทำทั้งหมดนี้ ก็ถึงเวลาคิดงบประมาณ แน่นอนว่าฉันพบสิ่งที่น่าสนใจมากมายในการที่เราใช้จ่ายเงินของเรา ตัวอย่างเช่น เรามีแร็คทั้งหมดในศูนย์ข้อมูลที่แยกจากกันโดยมีเซิร์ฟเวอร์ FTP หนึ่งเครื่อง ซึ่งไคลเอ็นต์หนึ่งเครื่องใช้ ปรากฎว่า “...เราย้ายแล้ว แต่เขาอยู่อย่างนั้น เราไม่ได้เปลี่ยนเขา” มันเป็นเมื่อ 2 ปีที่แล้ว

สิ่งที่น่าสนใจเป็นพิเศษคือการเรียกเก็บเงินสำหรับบริการคลาวด์ ฉันเชื่อว่าสาเหตุหลักของค่าใช้จ่ายคลาวด์ที่สูงคือนักพัฒนาที่สามารถเข้าถึงเซิร์ฟเวอร์ได้ไม่จำกัดเป็นครั้งแรกในชีวิต พวกเขาไม่จำเป็นต้องถามว่า: “โปรดมอบเซิร์ฟเวอร์ทดสอบให้ฉันหน่อย” พวกเขาสามารถนำไปเองได้ นอกจากนี้นักพัฒนามักต้องการสร้างระบบที่ยอดเยี่ยมจน Facebook และ Netflix ต้องอิจฉา

แต่นักพัฒนาไม่มีประสบการณ์ในการซื้อเซิร์ฟเวอร์และไม่มีทักษะในการกำหนดขนาดเซิร์ฟเวอร์ที่ต้องการ เนื่องจากก่อนหน้านี้พวกเขาไม่เคยต้องการมันมาก่อน และมักจะไม่ค่อยเข้าใจถึงความแตกต่างระหว่างความสามารถในการขยายขนาดและประสิทธิภาพ

ผลลัพธ์สินค้าคงคลัง:

• เราออกจากศูนย์ข้อมูลเดียวกัน
• เรายกเลิกสัญญาด้วยบริการบันทึก 3 รายการ เนื่องจากเรามี 5 ตัว - นักพัฒนาทุกคนที่เริ่มเล่นกับบางสิ่งบางอย่างก็เอาอันใหม่
• ระบบ AWS 7 ระบบถูกปิดตัวลง ขอย้ำอีกครั้งว่าไม่มีใครหยุดยั้งโครงการที่ตายแล้วได้ ทุกคนยังคงทำงานต่อไป
• ลดต้นทุนซอฟต์แวร์ลง 6 เท่า

วันที่เจ็ดสิบห้า

เวลาผ่านไปอีกสองเดือนครึ่งฉันต้องเข้าพบคณะกรรมการ คณะกรรมการของเราไม่ได้ดีหรือแย่กว่าบอร์ดอื่นๆ เช่นเดียวกับคณะกรรมการอื่นๆ ที่ต้องการทราบทุกอย่าง ผู้คนลงทุนเงินและต้องการเข้าใจว่าสิ่งที่เราทำนั้นเหมาะสมกับ KPI ที่ตั้งไว้มากเพียงใด

คณะกรรมการบริหารได้รับข้อมูลจำนวนมากทุกเดือน เช่น จำนวนผู้ใช้ การเติบโต บริการที่พวกเขาใช้และวิธีการ ประสิทธิภาพและประสิทธิผล และสุดท้ายคือ ความเร็วในการโหลดหน้าเว็บโดยเฉลี่ย

ปัญหาเดียวคือฉันเชื่อว่าค่าเฉลี่ยคือความชั่วร้ายล้วนๆ แต่เป็นเรื่องยากมากที่จะอธิบายเรื่องนี้ให้คณะกรรมการทราบ พวกเขาคุ้นเคยกับการทำงานด้วยจำนวนรวม และไม่ใช่ ตัวอย่างเช่น การกระจายเวลาในการโหลดต่อวินาที

มีประเด็นที่น่าสนใจในเรื่องนี้ ตัวอย่างเช่น ฉันบอกว่าเราจำเป็นต้องแบ่งการรับส่งข้อมูลระหว่างเว็บเซิร์ฟเวอร์ที่แยกจากกัน ขึ้นอยู่กับประเภทของเนื้อหา

นั่นคือ ColdFusion ผ่าน Jetty และ nginx และเปิดเพจต่างๆ และรูปภาพ, JS และ CSS จะต้องผ่าน nginx ที่แยกจากกันด้วยการกำหนดค่าของตัวเอง นี่เป็นแนวทางปฏิบัติที่ค่อนข้างเป็นมาตรฐานที่ฉันพูดถึง อ้าง สองสามปีที่ผ่านมา เป็นผลให้รูปภาพโหลดเร็วขึ้นมากและ... ความเร็วในการโหลดโดยเฉลี่ยเพิ่มขึ้น 200 มิลลิวินาที

สิ่งนี้เกิดขึ้นเนื่องจากกราฟสร้างขึ้นจากข้อมูลที่มาพร้อมกับ Jetty นั่นคือเนื้อหาด่วนไม่รวมอยู่ในการคำนวณ - ค่าเฉลี่ยเพิ่มขึ้น สิ่งนี้ชัดเจนสำหรับเรา เราหัวเราะ แต่เราจะอธิบายให้คณะกรรมการทราบได้อย่างไรว่าทำไมเราถึงทำอะไรบางอย่างและสิ่งต่างๆ แย่ลงถึง 12%

วันที่แปดสิบห้า

เมื่อสิ้นเดือนที่สาม ฉันตระหนักว่ามีสิ่งหนึ่งที่ฉันคาดไม่ถึงเลย นั่นก็คือ เวลา ทุกสิ่งที่ฉันพูดถึงต้องใช้เวลา

นี่คือปฏิทินรายสัปดาห์จริงๆ ของฉัน - แค่สัปดาห์ทำงาน ไม่ยุ่งมาก ไม่มีเวลาเพียงพอสำหรับทุกสิ่ง ดังนั้นคุณต้องรับสมัครคนที่จะช่วยคุณรับมือกับปัญหาอีกครั้ง

ข้อสรุป

นั่นไม่ใช่ทั้งหมด. ในเรื่องราวนี้ ฉันไม่เข้าใจเลยว่าเราทำงานกับผลิตภัณฑ์อย่างไรและพยายามปรับตัวให้เข้ากับคลื่นทั่วไป หรือวิธีที่เราบูรณาการการสนับสนุนทางเทคนิค หรือวิธีที่เราแก้ไขปัญหาทางเทคนิคอื่นๆ ตัวอย่างเช่น ฉันได้เรียนรู้โดยบังเอิญว่าเราไม่ได้ใช้ตารางที่ใหญ่ที่สุดในฐานข้อมูล SEQUENCE. เรามีฟังก์ชันที่เขียนเอง nextIDและไม่ได้ใช้ในการทำธุรกรรม

มีเรื่องที่คล้ายกันอีกนับล้านที่เราสามารถพูดถึงได้เป็นเวลานาน แต่สิ่งที่สำคัญที่สุดที่ยังต้องพูดถึงคือวัฒนธรรม

วัฒนธรรมหรือการขาดแคลนนั้นเองที่นำไปสู่ปัญหาอื่นๆ ทั้งหมด เรากำลังพยายามสร้างวัฒนธรรมที่ผู้คน:

• ไม่กลัวความล้มเหลว
• เรียนรู้จากความผิดพลาด
• ทำงานร่วมกับทีมอื่น
• ใช้ความคิดริเริ่ม;
• รับผิดชอบ;
• ยินดีกับผลลัพธ์ที่เป็นเป้าหมาย
• เฉลิมฉลองความสำเร็จ

ด้วยเหตุนี้ทุกสิ่งทุกอย่างจะมา

ลีออน ไฟร์ บนทวิตเตอร์, Facebook และ กลาง.

มีสองกลยุทธ์ที่เกี่ยวข้องกับมรดก: หลีกเลี่ยงการทำงานกับมันไม่ว่าจะด้วยวิธีใดก็ตาม หรือเอาชนะความยากลำบากที่เกี่ยวข้องอย่างกล้าหาญ เราค DevOpsConf เรากำลังใช้เส้นทางที่สอง เปลี่ยนแปลงกระบวนการและแนวทาง เข้าร่วมกับเราบน YouTube, รายชื่อผู้รับจดหมาย и โทรเลขและเราจะนำวัฒนธรรม DevOps มาใช้ร่วมกัน

ที่มา: will.com