10 năm cuộc giải cứu HealthCare.gov
(pauladamsmith.com)- Ngày 18/10/2013, ngay sau khi ra mắt, một nhóm kỹ thuật nhỏ bắt đầu đợt kiểm tra thực địa đầu tiên tại Nhà Trắng để hồi sinh HealthCare.gov đang bị tê liệt; công việc này về sau được gọi là “tech surge”
- Trang web được công bố ngày 1/10/2013 nhưng không hoạt động đúng cách; do chính phủ liên bang đóng cửa bắt đầu cùng ngày, hỗ trợ bên ngoài chỉ có thể được triển khai sau ngày 17/10
- Trong ngày đầu tiên, nhóm lần lượt ghé Nhà Trắng, HHS, CMS, Exchange Operations Center và văn phòng CGI để xác định các điểm nghẽn của một hệ thống quy mô lớn đan xen hợp đồng, thành phần, quy tắc nghiệp vụ và quy trình triển khai
- Tại hiện trường, các rủi ro chính lộ ra gồm kiểm thử thủ công, các đợt triển khai và rollback kéo dài vào ban đêm, cấp phát tài nguyên chậm, tầng dữ liệu lõi không có schema và thiếu giám sát thời gian thực
- Sau khi cài trực tiếp New Relic lên một số máy chủ tại văn phòng CGI, độ trễ, tỷ lệ lỗi và số lượng request lần đầu tiên bắt đầu hiện ra; trong khoảng 2 tháng rưỡi sau đó, công tác giải cứu được mở rộng và góp phần cải thiện trang web
Ngày 18/10/2013, khởi đầu của công tác giải cứu
- Công cuộc khôi phục HealthCare.gov chính thức bắt đầu lúc 7:15 sáng thứ Sáu, ngày 18/10/2013, với một nhóm nhỏ tập hợp gần lối vào West Wing của Nhà Trắng
- Nhóm ban đầu gồm Todd Park, Brian Holcomb, Gabriel Burt, Ryan Panchadsaram, Greg Gershman và Paul Smith; muộn hơn trong ngày hôm đó, Mikey Dickerson tham gia qua một cuộc gọi loa kéo dài
- Một số người đến từ bên ngoài chính phủ, một số khi đó đang làm việc trong chính phủ, nhưng tất cả đều là chuyên gia kỹ thuật có kinh nghiệm ở startup hoặc các tổ chức công nghệ lớn
- Todd Park, khi đó là CTO của Mỹ, đã tuyển chọn họ để tăng cường cho đội ngũ nhân viên chính phủ và nhà thầu đã xây dựng HealthCare.gov
- Nhiệm vụ không phải là “lao vào như kỵ binh”, mà giống hơn với việc hỗ trợ khiêm tốn: lặng lẽ bước vào một hiện trường vốn đã chịu nhiều áp lực và căng thẳng để thu thập thông tin và đánh giá
- Todd Park nói rằng 30 ngày tiếp theo rất quan trọng, và mục tiêu là đăng ký cho 7 triệu người trước khi giai đoạn ghi danh mở kết thúc vào ngày 31/3/2014
Khoảng trống do chính phủ đóng cửa và thất bại khi ra mắt tạo ra
- HealthCare.gov ra mắt ngày 1/10/2013 nhưng không hoạt động đúng cách, và cùng ngày đó chính phủ liên bang bắt đầu đóng cửa
- Vì việc đóng cửa này, nhân sự bên ngoài nhóm cốt lõi của HealthCare.gov không thể vào hỗ trợ
- Trong lúc đó, tin tức tràn ngập về việc chính phủ đóng cửa và thảm họa ra mắt diễn ra chậm chạp, khiến khoảng trống thông tin, suy đoán và lo ngại ngày càng lớn
- Nhà Trắng không nắm được điều gì đang trục trặc ở HealthCare.gov; nếu trang web thất bại, kênh cốt lõi để chuyển các quyền lợi của Affordable Care Act tới hàng triệu người có thể bị lung lay
- Việc đóng cửa kết thúc ngày 17/10, và chỉ khi đó nhóm kỹ thuật bên ngoài mới có thể nắm tình hình thực tế và bắt đầu làm việc
Bức tranh toàn cảnh của hệ thống được nắm bắt trong buổi sáng đầu tiên
- Sau khi ăn sáng tại Navy Mess của Nhà Trắng, nhóm đi lên văn phòng Chief of Staff để gặp Denis McDonough
- Denis McDonough hỏi thẳng “có sửa được không”, và một số thành viên trong nhóm, trong trạng thái căng thẳng, trả lời “có”
- Sau đó họ di chuyển đến Hubert H. Humphrey Building, trụ sở HHS, để gặp Marilyn Tavenner, người đứng đầu CMS, cùng đội ngũ tham mưu
- Tại đây, kiến trúc của HealthCare.gov, các thành phần chức năng chính, những vị trí lỗi mà lãnh đạo CMS biết và các vấn đề hiệu năng ở mức cao đã được chia sẻ
- Vì lãnh đạo CMS là các chuyên gia chính sách y tế và nhà quản trị, thông tin được truyền đạt chủ yếu gần với chỉ số kinh doanh của trang web và các mô tả hiệu năng ở mức cao
- Cuối buổi sáng, nhóm di chuyển đến trụ sở CMS ở Woodlawn, Maryland để gặp ban lãnh đạo HealthCare.gov, gồm Michelle Snyder, Henry Chao, Dave Nelson và những người khác
- Tại đây, các thông tin về vấn đề triển khai, điểm nghẽn, những chỗ người dùng bị “kẹt” trên trang, cơ sở dữ liệu XML MarkLogic, kiến trúc triển khai và loại máy chủ dần được hé lộ
Thực tế vận hành lộ ra tại XOC
- Buổi chiều, nhóm di chuyển đến Exchange Operations Center, tức XOC, ở Columbia, Maryland
- XOC là trung tâm kiểu mission control cho hoạt động vận hành HealthCare.gov, và tại đó nhóm nghe câu chuyện từ các kỹ thuật viên trực tiếp xử lý trang web
- Những vấn đề xác nhận tại hiện trường nghiêm trọng hơn nhiều so với dự đoán ban đầu
- Có sự thiếu tin cậy đối với các thay đổi mã nguồn
- Nhiều phần của trang web được tạo ra bằng các quy trình sinh mã phức tạp, đòi hỏi phối hợp tỉ mỉ giữa các nhóm
- Kiểm thử phần lớn là quy trình thủ công
- Release và triển khai đòi hỏi downtime dài vào ban đêm, và nếu thất bại sẽ kéo theo rollback kéo dài
- Tầng dữ liệu lõi không có schema
- Việc cấp phát tài nguyên hosting chậm và không được tự động hóa
- Không chỉ APM, ngay cả các chỉ số cơ bản như CPU, bộ nhớ, ổ đĩa và mạng cũng chưa được thiết lập theo cách nhóm có thể xem được
- Đến thời điểm này, nhóm chấp nhận rằng tình hình tệ hơn nhiều so với dự đoán ban đầu, và Paul Smith vội ghi lại những gì nghe được vào sổ Moleskine
Đêm gắn New Relic tại văn phòng CGI
- Buổi tối, nhóm di chuyển đến văn phòng CGI ở Herndon, Virginia
- CGI là nhà thầu chính của HealthCare.gov, và nhóm gặp ban lãnh đạo cùng đội kỹ thuật để đặt câu hỏi
- Trong cuộc gặp này, điều quan trọng là nhóm kỹ thuật bên ngoài phải giành được niềm tin của đội CGI
- Đội CGI đang chịu áp lực và kiệt sức
- Nhóm giải cứu nhấn mạnh rằng họ không đến để đổ lỗi mà để giúp đỡ
- Họ cố thể hiện năng lực kỹ thuật dựa trên kinh nghiệm với các website lưu lượng cao
- Câu hỏi cốt lõi là “trang web đang sai ở đâu, và làm sao biết điều đó”, nhưng CMS và CGI hầu như không thể chỉ ra phần lớn các vị trí bên trong hệ thống nơi một thành phần cụ thể không hoạt động như kỳ vọng
- Nhóm đề xuất thử cài New Relic, một dịch vụ giám sát kiểu APM quen thuộc, lên một số máy chủ
- Họ bỏ qua quy trình release thông thường và cài trực tiếp agent lên một số máy chủ được chọn; sau khi một lãnh đạo CMS xác nhận đã có giấy phép New Relic, việc này được phê duyệt
- Những người còn ở lại đến gần nửa đêm tiến hành thay đổi, và trên màn hình phòng họp, giao diện quản trị New Relic cho thấy các máy chủ “red shard” được chọn bắt đầu gửi chỉ số
- Lần đầu tiên, các chỉ số vận hành thời gian thực như mức tăng vọt độ trễ request, tỷ lệ lỗi và số request mỗi phút hiện ra, làm lộ trạng thái hệ thống vốn trước đó gần như vô hình
- Nhờ các chỉ số này, họ có cơ sở để kết nối chỉ số kinh doanh với trạng thái hệ thống, đồng thời ưu tiên các bản sửa và hành động có thể đem lại cải thiện lớn nhất
Sau ngày đầu tiên kéo dài 18 giờ
- Sau khi rời Herndon, nhóm có một buổi hồi tưởng ngắn vào khoảng 2 giờ sáng trong Roosevelt Room yên tĩnh của Nhà Trắng
- Đến lúc này, nhóm chấp nhận rằng vấn đề không phải quy mô có thể kết thúc bằng vài lời tư vấn ngắn hạn, và họ sẽ phải bám sát công việc này trong một thời gian cho đến khi trang web phục hồi
- Sau khi ngủ vài tiếng, sáng hôm sau họ lại hướng tới Herndon
- Lịch trình ngày đầu tiên kéo dài khoảng 18 giờ, và những cuộc marathon tương tự tiếp tục sau đó
- Đến cuối tháng 12, trong khoảng 2 tháng rưỡi, tech surge được mở rộng, các thành viên mới gia nhập và giúp cải thiện HealthCare.gov
- Năm đó, hàng triệu người đã đăng ký bảo hiểm y tế, và với nhiều người, đó là lần đầu tiên
1 bình luận
Ý kiến trên Hacker News
Ý định ban đầu là mỗi bang sẽ vận hành sàn giao dịch riêng, và chỉ cư dân của các bang từ chối làm vậy mới dùng sàn giao dịch liên bang
Ban đầu có 36 bang không lập sàn giao dịch riêng 0, còn hiện nay có vẻ 20 bang, tính cả D.C., đang vận hành marketplace riêng 1
Việc chính phủ đóng cửa năm 2013, khiến nhân lực ngoài đội phụ trách HealthCare.gov của các bang không thể vào hỗ trợ, là do Thượng nghị sĩ Ted Cruz dẫn dắt với mục đích cản trở ACA 2
Tôi cảm thấy nguyên tắc “mỗi bang độc lập” của Mỹ đôi khi bị đẩy đi quá xa
Họ lo rằng một hệ thống y tế liên bang cuối cùng sẽ dẫn tới bảo hiểm y tế phổ cập, và sau khi đạt được thỏa hiệp, họ đã từ chối triển khai sàn giao dịch với hy vọng đạo luật sẽ chết yểu
Nhưng đạo luật đã không chết, và họ đến giờ vẫn không hài lòng về điều đó
Kết quả của việc chuyển ngân sách liên bang thành các khoản trợ cấp trọn gói theo bang, rồi để bang phụ trách các chương trình như TANF và xét duyệt điều kiện 1 là hiệu quả biến mỗi 1 đô la ngân sách liên bang thành hỗ trợ thực tế, cũng như số người và số tiền được hỗ trợ, đều xấu đi đáng kể
Tôi không biết cơ sở của marketplace cấp bang trong ACA là gì, nhưng về mặt lịch sử, cứ đưa bang vào là lại tăng khả năng bên trung gian làm hỏng chương trình và chuyển tiền sang chỗ khác
Ví dụ Texas đã từ chối khoản tiền miễn phí 5–6 tỷ đô la mỗi năm mà chính phủ liên bang định cấp để mở rộng Medicaid 2
Có vẻ nhiều lần các bài đó nói rằng một công ty bảo hiểm bị lỗ vì một số ít bệnh nhân có chi phí điều trị rất cao, rồi khi chi phí đó tăng quá lớn và họ tăng giá thì không ai muốn mua sản phẩm ấy nữa
Gần đây tôi thử tìm lại các bài đó nhưng không còn thấy, nên không rõ có phải mình tưởng tượng ra không
Có tiền và sẵn sàng giao dịch mà vẫn không làm được, nên hệ thống này là thất bại
Tôi vẫn nhớ đã làm việc cùng những người này khi tất cả bị kéo vào để sửa nó
Gabe code bằng VIM trông như một nghệ sĩ violin bậc thầy, còn khi làm việc với Mikey tôi đã thấy sức mạnh của chỉ số và SRE
Từ tình trạng mọi người trong phòng đều chỉ tay đổ lỗi cho vendor kế tiếp, mọi thứ chuyển sang việc thực sự tìm ra một phần các nút thắt cổ chai
Nói chung, sửa một hệ thống hỏng mà không thể đưa nó offline để refactor lớn chẳng khác nào phẫu thuật cho một người đang chạy bộ, và đó là một trải nghiệm thật sự dữ dội
Một startup nhỏ ở D.C. chỉ là nhà thầu phụ của nhà thầu phụ của nhà thầu phụ phụ trách landing page phía trước, nhưng tôi vẫn nhớ vui vì đã có thể khiến mọi người đến được trang thật trên healthcare.gov chứ không phải trang lỗi 500
Nếu tôi nhớ không nhầm thì đó là nhờ một máy chủ đơn lẻ dùng Jekyll và một máy dự phòng
Theo cách gọi hiện nay thì đó là phương thức “tạo trang tĩnh”, nên có thể host được cả trên phần cứng nhỏ
Thời đó đây được xem là một chiến thuật khá tiên tiến, và có lẽ đây là điều người kia đang nhớ tới
Theo tôi biết, website đó đã được thay thế hoàn toàn khi sàn giao dịch liên bang mở cửa, và bản thân landing page không nhận hay xử lý thông tin cá nhân nên việc cung cấp nó không gặp trở ngại lớn
Mọi thứ chỉ khựng lại sau khi người dùng bắt đầu thực sự tìm các gói bảo hiểm
Development Seed sau đó cũng tạo ra một dự án khác mà có thể bạn đã nghe đến: Mapbox, và cuối cùng cả công ty chuyển hẳn sang hướng đó
Tôi nhớ từng nghe trong một podcast rằng thay vì hiển thị lỗi “backend timeout” như một lỗi, họ đổi sang gửi dữ liệu qua email và nói với người dùng: “Ổn rồi, chúng tôi đã nhận được. Hãy quay lại kiểm tra sau”
Tôi nghĩ cách đó rất thông minh, và ghi nhớ như một phương án có thể dùng khi khẩn cấp sau này
Ở WebTV cũng từng có chuyện tương tự khi cơ sở dữ liệu quá tải: họ tắt toàn bộ các máy chủ chuyển tiếp mail ở bước cuối vốn cần kết nối cơ sở dữ liệu, để mail được xếp hàng ở các máy chủ SMTP inbound, rồi xả hàng đợi sau khi tình trạng quá tải cơ sở dữ liệu được giải quyết
Bài học là: để giảm tải cho một hệ thống vốn được thiết kế hoạt động theo kiểu giao dịch nhưng đang thất bại, hãy dùng xử lý thiên về batch được xử lý từ hàng đợi
Tập podcast “Go Time” về chủ đề này rất hay, nói về việc họ đã dùng Go như thế nào để phục vụ một phần của trang web
Rất khuyến nghị tập này và cả podcast đó
https://changelog.com/gotime/154
Tôi bấm vào vì nghĩ đây sẽ là một cuộc thảo luận kỹ thuật thú vị, nhưng phần nói về kỹ thuật phải khá lâu sau mới xuất hiện
Thay vào đó, hậu trường của quy trình lại thú vị ngoài mong đợi, và tôi thật sự mong chờ phần tiếp theo
Đọc bài này thật sự rất thích
Tôi nhớ 10 năm trước trên HN, mọi người mổ xẻ kỹ mã nguồn GitHub của website: https://news.ycombinator.com/item?id=6540993
Những gì thực sự xảy ra không hề lý tưởng, nhưng ngoài bài hồi tưởng này, tôi tò mò liệu có tài liệu nào giải thích chi tiết hơn chính xác chuyện gì đã xảy ra và nó được khắc phục ra sao không
Tôi sẽ tiếp tục tìm đọc các bài tiếp theo trong loạt này
Có cảm giác hơi giống kiểu porn về năng lực kỹ thuật, nhưng tôi thích những câu chuyện như vậy
Vài năm trước tôi đã đọc The Phoenix Project; dù đó là sách được tiểu thuyết hóa và giới thiệu khá lộ liễu về Agile và DevOps, với tư cách là một nhà phân tích dữ liệu thì tôi thấy nó mới mẻ và hay, nên nếu có gợi ý tương tự tôi cũng muốn đọc thử
Trích một đoạn hay: Dickerson đã dán các quy tắc lên bức tường ngay bên ngoài phòng điều hành
Quy tắc 1: “War room và các cuộc họp là để giải quyết vấn đề. Có rất nhiều chỗ khác để dùng năng lượng sáng tạo vào việc đổ lỗi.”
Quy tắc 2: “Người cần lên tiếng về một vấn đề không phải là người có chức vụ cao nhất, mà là người hiểu vấn đề đó rõ nhất. Nếu ai đó ngồi thụ động trong khi các quản lý và lãnh đạo cấp cao nói bằng thông tin kém chính xác hơn, thì chúng ta đã đi chệch hướng, và tôi muốn biết điều đó.” Dickerson sau này giải thích: “Khi gạt các quản lý sang một bên, các kỹ sư muốn giải quyết vấn đề.”
Quy tắc 3: “Chúng ta phải tập trung vào những vấn đề cấp bách nhất có thể gây hại cho mình trong 24–48 giờ tới.”
Cách giải là đừng tiếp tục giao những việc như thế này cho cùng các công ty đó nữa
Rõ ràng các công ty như CGI, IBM không đủ năng lực, vậy mà tôi không hiểu vì sao họ không bị cấm tham gia đấu thầu trong các hợp đồng tương tự về sau
Nếu làm hỏng một hợp đồng, cứ loại họ khỏi mọi hợp đồng chính phủ trong 10 năm tiếp theo là được
Như vậy ta sẽ có công nghệ thực sự hoạt động, thay vì cứ luẩn quẩn với những sản phẩm rác rưởi
Vì vậy các công ty nhỏ khó tham gia cạnh tranh
Hoặc trộn lại các đội ngũ với nhau là xong
Chẳng mấy chốc sẽ chẳng còn ai nhận việc nữa
“Một số công nghệ cụ thể, bao gồm cơ sở dữ liệu XML tên là MarkLogic” — cơ sở dữ liệu XML cho một dịch vụ cốt lõi có 300 triệu người dùng ư?
Rợn người
Có lẽ các quy tắc nghiệp vụ nằm trong XML và về cơ bản là chỉ đọc, còn dữ liệu động thì nằm trong cơ sở dữ liệu quan hệ
Hoặc có thể đó chỉ là suy đoán đầy hy vọng của tôi
Có thể nó là cơ sở dữ liệu cấu hình, nhưng nghe như vấn đề phát sinh từ logic nghiệp vụ, nên bản thân điều đó cũng có thể đã là vấn đề