เรื่องราวการเปิดตัวที่ส่งผลต่อทุกสิ่ง

ศัตรูของความเป็นจริง โดย 12f-2

เมื่อปลายเดือนเมษายน ขณะที่ White Walkers กำลังปิดล้อม Winterfell มีบางอย่างที่น่าสนใจกว่าเกิดขึ้นกับเรา เราได้เปิดตัวที่ผิดปกติ โดยหลักการแล้ว เรากำลังเปิดตัวฟีเจอร์ใหม่ๆ ในการใช้งานจริงอย่างต่อเนื่อง (เช่นเดียวกับคนอื่นๆ) แต่อันนี้แตกต่างออกไป ข้อผิดพลาดที่อาจเกิดขึ้นจะส่งผลกระทบต่อบริการและผู้ใช้ทั้งหมดของเรา ด้วยเหตุนี้ เราจึงดำเนินการทุกอย่างตามแผน ภายในระยะเวลาหยุดทำงานที่วางแผนไว้และประกาศ โดยไม่มีผลกระทบต่อการขาย บทความนี้เกี่ยวกับวิธีที่เราบรรลุเป้าหมายนี้ และวิธีที่ทุกคนสามารถทำซ้ำได้ที่บ้าน

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

พื้นหลัง + ฟังก์ชั่นนี้คืออะไร?

เรากำลังสร้างแพลตฟอร์มคลาวด์ Mail.ru โซลูชั่นคลาวด์ (MCS) โดยที่ฉันทำงานเป็นผู้อำนวยการด้านเทคนิค และตอนนี้ก็ถึงเวลาเพิ่ม IAM (การจัดการข้อมูลประจำตัวและการเข้าถึง) ให้กับแพลตฟอร์มของเรา ซึ่งให้การจัดการแบบรวมศูนย์สำหรับบัญชีผู้ใช้ ผู้ใช้ รหัสผ่าน บทบาท บริการ และอื่นๆ ทั้งหมด เหตุใดจึงต้องมีสิ่งนี้ในระบบคลาวด์เป็นคำถามที่ชัดเจน: ข้อมูลผู้ใช้ทั้งหมดถูกจัดเก็บไว้ในนั้น

โดยปกติแล้วสิ่งเหล่านี้จะเริ่มถูกสร้างขึ้นในช่วงเริ่มต้นของโครงการใด ๆ แต่ในอดีตสิ่งต่าง ๆ ใน MCS นั้นแตกต่างออกไปเล็กน้อย MCS ถูกสร้างขึ้นเป็นสองส่วน:

• OpenStack พร้อมโมดูลการอนุญาต Keystone ของตัวเอง
• Hotbox (ที่เก็บข้อมูล S3) ตามโครงการ Mail.ru Cloud

ซึ่งบริการใหม่ ๆ ก็ปรากฏขึ้น

โดยพื้นฐานแล้ว การอนุญาตเหล่านี้มีสองประเภทที่แตกต่างกัน นอกจากนี้เรายังใช้การพัฒนา Mail.ru ที่แยกจากกัน เช่น พื้นที่จัดเก็บรหัสผ่าน Mail.ru ทั่วไป รวมถึงตัวเชื่อมต่อ openid ที่เขียนขึ้นเอง ซึ่งต้องขอบคุณ SSO (การอนุญาตจากต้นทางถึงปลายทาง) ที่ให้ไว้ในแผง Horizon ของเครื่องเสมือน (OpenStack UI ดั้งเดิม)

การสร้าง IAM ให้กับเราหมายถึงการเชื่อมต่อทั้งหมดไว้ในระบบเดียวซึ่งเป็นของเราเองโดยสมบูรณ์ ในเวลาเดียวกัน เราจะไม่สูญเสียฟังก์ชันการทำงานใดๆ ในระหว่างนี้ แต่จะสร้างรากฐานสำหรับอนาคตที่จะช่วยให้เราปรับแต่งได้อย่างโปร่งใสโดยไม่ต้องปรับโครงสร้างใหม่และปรับขนาดในแง่ของฟังก์ชันการทำงาน นอกจากนี้ ในช่วงเริ่มต้น ผู้ใช้ยังมีแบบอย่างในการเข้าถึงบริการ (RBAC กลาง การควบคุมการเข้าถึงตามบทบาท) และเรื่องเล็กๆ น้อยๆ อื่นๆ

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

เราจะเปิดตัวอะไร?

พูดคร่าวๆ ในเวลาประมาณ 4 เดือน เราได้เตรียมสิ่งต่อไปนี้:

• เราได้สร้าง daemons ใหม่ขึ้นมาหลายรายการที่รวบรวมฟังก์ชันต่างๆ ที่เคยทำงานในส่วนต่างๆ ของโครงสร้างพื้นฐานไว้ด้วยกัน บริการที่เหลือได้รับการกำหนดแบ็กเอนด์ใหม่ในรูปแบบของปีศาจเหล่านี้
• เราเขียนที่จัดเก็บข้อมูลรหัสผ่านและกุญแจส่วนกลางของเราเอง ซึ่งใช้ได้กับบริการทั้งหมดของเรา ซึ่งสามารถแก้ไขได้โดยอิสระตามที่เราต้องการ
• เราเขียนแบ็กเอนด์ใหม่ 4 รายการสำหรับ Keystone ตั้งแต่เริ่มต้น (ผู้ใช้ โปรเจ็กต์ บทบาท การมอบหมายบทบาท) ซึ่งอันที่จริงได้เข้ามาแทนที่ฐานข้อมูล และตอนนี้ทำหน้าที่เป็นที่เก็บข้อมูลเดียวสำหรับรหัสผ่านผู้ใช้ของเรา
• เราสอนบริการของ OpenStack ทั้งหมดของเราให้ไปที่บริการนโยบายของบริษัทอื่นสำหรับนโยบายของพวกเขา แทนที่จะอ่านนโยบายเหล่านี้ภายในเครื่องจากแต่ละเซิร์ฟเวอร์ (ใช่แล้ว นั่นคือวิธีการทำงานของ Openstack ตามค่าเริ่มต้น!)

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

จะนำการเปลี่ยนแปลงดังกล่าวไปใช้อย่างไรและไม่ทำให้เสียหาย? ก่อนอื่นเราตัดสินใจที่จะมองไปสู่อนาคตสักหน่อย

กลยุทธ์การเปิดตัว

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

การพูดนอกเรื่อง: การเปิดตัวคืออะไร?

<ข้อควรระวัง ปรัชญา>

ผู้เชี่ยวชาญด้านไอทีทุกคนสามารถตอบได้อย่างง่ายดายว่าการเปิดตัวคืออะไร คุณติดตั้ง CI/CD และทุกอย่างจะถูกส่งไปยังร้านค้าโดยอัตโนมัติ 🙂

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

และภาพรวมทั้งหมดก็เป็นเช่นนี้ การเปิดตัวประกอบด้วยสี่ประเด็นหลัก:

1. การส่งมอบโค้ดรวมถึงการแก้ไขข้อมูล ตัวอย่างเช่น การอพยพของพวกเขา
2. การย้อนกลับโค้ดคือความสามารถในการย้อนกลับหากมีสิ่งผิดปกติเกิดขึ้น เช่น ผ่านการสร้างข้อมูลสำรอง
3. เวลาของการดำเนินการเปิดตัว/ย้อนกลับแต่ละครั้ง คุณต้องเข้าใจจังหวะเวลาของการดำเนินการใดๆ ของสองจุดแรก
4. ฟังก์ชั่นการทำงานที่ได้รับผลกระทบ มีความจำเป็นต้องประเมินทั้งผลกระทบเชิงบวกและเชิงลบที่อาจเกิดขึ้น

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

องก์ที่ 1..n เตรียมออกตัว

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

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

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

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

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

แล้วก็…

การกระทำครั้งสุดท้ายก่อนที่จะเปิดตัว

...ถึงเวลาเปิดตัวแล้ว

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

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

1. ส่งผลกระทบต่อโครงสร้างพื้นฐานของผู้ใช้ (ศักดิ์สิทธิ์สำหรับเรา ล้ำค่าที่สุด)
2. ฟังก์ชั่นการใช้งาน: การใช้บริการของเราหลังการเปิดตัวควรจะเหมือนเดิม

กลิ้งออกไป

สองม้วน 8 ไม่รบกวน

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

• การเปิดตัวใช้เวลาประมาณ 3 ชั่วโมง
• 2 ชั่วโมงสำหรับการทดสอบ
• 2 ชั่วโมง - สงวนไว้สำหรับการย้อนกลับการเปลี่ยนแปลงที่เป็นไปได้

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

ชิ้นส่วนของแผนภูมิ Gantt ที่เปิดตัว ซึ่งเป็นหนึ่งในเวอร์ชันแรกๆ (ไม่มีการดำเนินการแบบขนาน) เครื่องมือซิงโครไนซ์ที่คุ้มค่าที่สุด

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

พงศาวดารของเหตุการณ์

จึงมาทำงานวันอาทิตย์ที่ 15 เมษายน เวลา 29 น. จำนวน 10 คน นอกจากผู้เข้าร่วมคนสำคัญแล้ว บางคนมาเพียงเพื่อสนับสนุนทีม ซึ่งต้องขอบคุณพวกเขาเป็นพิเศษ

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

00:00 น. หยุด
เราหยุดคำขอของผู้ใช้ วางป้ายบอกว่างานด้านเทคนิค การตรวจสอบกรีดร้อง แต่ทุกอย่างเป็นปกติ เราตรวจสอบว่าไม่มีอะไรล้มนอกจากสิ่งที่ควรจะตก และเราเริ่มทำงานเรื่องการโยกย้าย

ทุกคนมีแผนการเปิดตัวแบบพิมพ์ทีละจุด ทุกคนรู้ว่าใครกำลังทำอะไรและในเวลาใด หลังจากดำเนินการแต่ละอย่าง เราจะตรวจสอบกำหนดเวลาเพื่อให้แน่ใจว่าจะไม่เกินนั้น และทุกอย่างเป็นไปตามแผน ผู้ที่ไม่ได้มีส่วนร่วมในการเปิดตัวโดยตรงในขั้นตอนปัจจุบันกำลังเตรียมเปิดตัวของเล่นออนไลน์ (Xonotic ประเภท 3 quacks) เพื่อไม่ให้รบกวนเพื่อนร่วมงาน 🙂

02:00. รีดออกแล้ว
เป็นเรื่องที่น่าประหลาดใจ - เราเปิดตัวเสร็จเร็วขึ้นหนึ่งชั่วโมง เนื่องจากการเพิ่มประสิทธิภาพฐานข้อมูลและสคริปต์การย้ายข้อมูลของเรา เสียงร้องทั่วไป “แผ่ออกไป!” ฟังก์ชั่นใหม่ทั้งหมดอยู่ในการใช้งานจริง แต่จนถึงตอนนี้มีเพียงเราเท่านั้นที่เห็นได้ในอินเทอร์เฟซ ทุกคนเข้าสู่โหมดทดสอบ จัดเรียงพวกเขาออกเป็นกลุ่ม และเริ่มดูว่าเกิดอะไรขึ้นในที่สุด

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

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

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

03:00. -2 ปัญหา +2 ปัญหา
ปัญหาใหญ่สองปัญหาก่อนหน้านี้ได้รับการแก้ไขแล้ว และปัญหารองเกือบทั้งหมดก็เช่นกัน ผู้ที่ว่างในการแก้ไขกำลังทำงานอย่างแข็งขันในบัญชีของตนและรายงานสิ่งที่พวกเขาพบ เราจัดลำดับความสำคัญ แจกจ่ายระหว่างทีม และทิ้งสิ่งที่ไม่สำคัญไว้ในตอนเช้า

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

03:20. การซิงค์ฉุกเฉิน
แก้ไขปัญหาใหม่หนึ่งรายการแล้ว ประการที่สอง เรากำลังจัดการซิงค์ฉุกเฉิน เราเข้าใจสิ่งที่เกิดขึ้น: การแก้ไขก่อนหน้านี้แก้ไขปัญหาหนึ่ง แต่สร้างอีกปัญหาขึ้นมา เราหยุดพักเพื่อหาวิธีทำอย่างถูกต้องและไม่มีผลกระทบ

03:30. หกตา
เราเข้าใจว่าสถานะสุดท้ายของฐานควรเป็นอย่างไรเพื่อให้ทุกอย่างเป็นไปด้วยดีสำหรับพันธมิตรทุกคน เราเขียนคำขอด้วย 6 ตา เผยแพร่ในช่วงก่อนการผลิต ทดสอบ และเผยแพร่เพื่อการผลิต

04:00 น. ทุกอย่างทำงานได้
ผ่านการทดสอบทั้งหมด ไม่พบปัญหาร้ายแรงใดๆ ในบางครั้ง บางอย่างในทีมใช้ไม่ได้กับใครบางคน เราก็จะตอบสนองทันที ส่วนใหญ่แล้วสัญญาณเตือนจะเป็นเท็จ แต่บางครั้งมีบางอย่างมาไม่ถึงหรือหน้าแยกไม่ทำงาน เรานั่งซ่อมซ่อมซ่อม ทีมที่แยกออกมากำลังเปิดตัวฟีเจอร์สำคัญสุดท้าย - การเรียกเก็บเงิน

04:30. จุดที่ไม่มีทางหวนกลับ
จุดของการไม่คืนกำลังใกล้เข้ามา นั่นคือเวลาที่ถ้าเราเริ่มย้อนกลับ เราก็จะไม่พบกับการหยุดทำงานที่เรากำหนดไว้ มีปัญหากับการเรียกเก็บเงินซึ่งรู้และบันทึกทุกอย่าง แต่ปฏิเสธที่จะตัดเงินจากลูกค้าอย่างดื้อรั้น มีข้อบกพร่องหลายประการในแต่ละหน้า การดำเนินการ และสถานะ ฟังก์ชั่นหลักใช้งานได้ดี การทดสอบทั้งหมดผ่านการทดสอบเรียบร้อยแล้ว เราตัดสินใจว่ามีการเปิดตัวแล้ว เราจะไม่ย้อนกลับ

06:00 น. เปิดสำหรับทุกคนใน UI
แก้ไขข้อบกพร่องแล้ว บางส่วนที่ไม่ดึงดูดผู้ใช้จะถูกทิ้งไว้ในภายหลัง เราเปิดอินเทอร์เฟซให้กับทุกคน เรายังคงดำเนินการเรียกเก็บเงินต่อไป โดยรอความคิดเห็นจากผู้ใช้และติดตามผลลัพธ์

07:00 น. ปัญหาเกี่ยวกับการโหลด API
เห็นได้ชัดว่าเราวางแผนโหลดบน API ของเราผิดเล็กน้อยและทดสอบโหลดนี้ ซึ่งไม่สามารถระบุปัญหาได้ เป็นผลให้คำขอ 5% ล้มเหลว มาระดมพลและค้นหาสาเหตุกัน

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

08:00 น. แก้ไข API
เราได้ดำเนินการแก้ไขสำหรับโหลดแล้ว ความล้มเหลวก็หายไป เราเริ่มกลับบ้าน

10:00 น. ทั้งหมด
ทุกอย่างได้รับการแก้ไขแล้ว การติดตามดูเงียบๆ และถึงที่ ลูกค้าทีมงานก็ค่อย ๆ หลับไป การเรียกเก็บเงินยังคงอยู่ เราจะกู้คืนในวันพรุ่งนี้

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

การเปิดตัวครั้งนี้ก็ประสบความสำเร็จ! แน่นอนว่ามันอาจจะดีกว่านี้ แต่เราได้ข้อสรุปเกี่ยวกับสิ่งที่ไม่เพียงพอสำหรับเราที่จะบรรลุความสมบูรณ์แบบ

เบ็ดเสร็จ

ในช่วง 2 เดือนของการเตรียมการเปิดตัว มีงาน 43 งานเสร็จสมบูรณ์ ซึ่งกินเวลาตั้งแต่สองสามชั่วโมงไปจนถึงหลายวัน

ระหว่างการเปิดตัว:

• ปีศาจใหม่และที่เปลี่ยนแปลง - 5 ชิ้นแทนที่ 2 เสาหิน
• การเปลี่ยนแปลงภายในฐานข้อมูล - ฐานข้อมูลทั้งหมด 6 ฐานข้อมูลของเราที่มีข้อมูลผู้ใช้ได้รับผลกระทบ การดาวน์โหลดจากฐานข้อมูลเก่าสามฐานข้อมูลไปยังฐานข้อมูลใหม่หนึ่งฐานข้อมูลเสร็จสมบูรณ์แล้ว
• ส่วนหน้าที่ออกแบบใหม่ทั้งหมด
• จำนวนโค้ดที่ดาวน์โหลด - โค้ดใหม่ 33 บรรทัด, โค้ด 3 บรรทัดในการทดสอบ, โค้ดการย้ายข้อมูล 5 บรรทัด;
• ข้อมูลทั้งหมดไม่เสียหาย ไม่มีเครื่องเสมือนของลูกค้ารายเดียวเสียหาย 🙂

แนวปฏิบัติที่ดีสำหรับการเปิดตัวที่ดี

พวกเขานำทางเราในสถานการณ์ที่ยากลำบากนี้ แต่โดยทั่วไปแล้ว การติดตามสิ่งเหล่านี้ระหว่างการเปิดตัวใดๆ ก็มีประโยชน์ แต่ยิ่งการเปิดตัวซับซ้อนมากขึ้นเท่าใด บทบาทก็ยิ่งมากขึ้นเท่านั้น

1. สิ่งแรกที่คุณต้องทำคือทำความเข้าใจว่าการเปิดตัวจะส่งผลต่อผู้ใช้อย่างไร จะมีการหยุดทำงานหรือไม่? ถ้าเป็นเช่นนั้นการหยุดทำงานคืออะไร? สิ่งนี้จะส่งผลต่อผู้ใช้อย่างไร? สถานการณ์กรณีที่ดีที่สุดและเลวร้ายที่สุดที่เป็นไปได้คืออะไร? และครอบคลุมความเสี่ยง
2. วางแผนทุกอย่าง. ในแต่ละขั้นตอน คุณต้องเข้าใจทุกแง่มุมของการเปิดตัว:
   • การจัดส่งรหัส
   • การย้อนกลับโค้ด
   • เวลาของการดำเนินการแต่ละครั้ง
   • ฟังก์ชั่นที่ได้รับผลกระทบ
3. เล่นผ่านสถานการณ์ต่างๆ จนกระทั่งทุกขั้นตอนของการเปิดตัว รวมถึงความเสี่ยงในแต่ละขั้นตอนชัดเจน หากคุณมีข้อสงสัยใดๆ คุณสามารถหยุดพักและตรวจสอบขั้นตอนที่น่าสงสัยแยกกัน
4. แต่ละขั้นตอนสามารถและควรได้รับการปรับปรุงหากช่วยผู้ใช้ของเรา ตัวอย่างเช่น จะช่วยลดเวลาหยุดทำงานหรือขจัดความเสี่ยงบางประการ
5. การทดสอบย้อนกลับมีความสำคัญมากกว่าการทดสอบการส่งโค้ด มีความจำเป็นต้องตรวจสอบว่าเนื่องจากการย้อนกลับระบบจะกลับสู่สถานะเดิมและยืนยันสิ่งนี้ด้วยการทดสอบ
6. ทุกสิ่งที่สามารถเป็นอัตโนมัติได้ควรเป็นอัตโนมัติ ทุกสิ่งที่ไม่สามารถเป็นแบบอัตโนมัติได้ควรเขียนไว้ล่วงหน้าในเอกสารสรุป
7. บันทึกเกณฑ์ความสำเร็จ ควรมีฟังก์ชันอะไรบ้างและในเวลาใด? หากไม่เกิดขึ้น ให้รันแผนย้อนกลับ
8. และที่สำคัญที่สุด - ผู้คน ทุกคนควรตระหนักถึงสิ่งที่พวกเขากำลังทำ ทำไม และสิ่งที่ขึ้นอยู่กับการกระทำของพวกเขาในกระบวนการเปิดตัว

และในประโยคเดียว ด้วยการวางแผนและรายละเอียดที่ดี คุณสามารถนำเสนอสิ่งที่คุณต้องการได้โดยไม่มีผลกระทบต่อการขาย แม้แต่บางสิ่งที่จะส่งผลต่อบริการทั้งหมดของคุณในการผลิต

ที่มา: will.com