bởi 12f-2
Vào cuối tháng XNUMX, trong khi White Walkers đang bao vây Winterfell, một điều thú vị hơn đã xảy ra với chúng tôi; chúng tôi đã thực hiện một đợt triển khai bất thường. Về nguyên tắc, chúng tôi liên tục đưa các tính năng mới vào sản xuất (giống như những người khác). Nhưng cái này khác. Quy mô của nó đến mức bất kỳ lỗi tiềm ẩn nào chúng tôi có thể mắc phải sẽ ảnh hưởng đến tất cả các dịch vụ và người dùng của chúng tôi. Do đó, chúng tôi đã triển khai mọi thứ theo kế hoạch, trong khoảng thời gian ngừng hoạt động đã được lên kế hoạch và thông báo mà không ảnh hưởng đến doanh số bán hàng. Bài viết nói về cách chúng tôi đạt được điều này và cách mọi người có thể lặp lại nó ở nhà.
Bây giờ tôi sẽ không mô tả các quyết định về kiến trúc và kỹ thuật mà chúng tôi đã đưa ra hoặc cho biết tất cả hoạt động như thế nào. Đây là những ghi chú bên lề về cách diễn ra một trong những đợt triển khai khó khăn nhất mà tôi đã quan sát và trực tiếp tham gia. Tôi không khẳng định sự đầy đủ hoặc chi tiết kỹ thuật; có lẽ chúng sẽ xuất hiện trong một bài viết khác.
Bối cảnh + đây là loại chức năng gì?
Chúng tôi đang xây dựng nền tảng đám mây (MCS), nơi tôi làm giám đốc kỹ thuật. Và bây giờ là lúc thêm IAM (Quản lý danh tính và quyền truy cập) vào nền tảng của chúng tôi, nền tảng này cung cấp khả năng quản lý thống nhất tất cả tài khoản người dùng, người dùng, mật khẩu, vai trò, dịch vụ, v.v. Tại sao nó lại cần thiết trên đám mây là một câu hỏi hiển nhiên: tất cả thông tin người dùng đều được lưu trữ trong đó.
Thông thường những thứ như vậy bắt đầu được xây dựng ngay từ đầu bất kỳ dự án nào. Nhưng về mặt lịch sử, mọi thứ ở MCS có một chút khác biệt. MCS được xây dựng thành hai phần:
- Openstack với mô-đun ủy quyền Keystone của riêng nó,
- Hotbox (bộ lưu trữ S3) dựa trên dự án Mail.ru Cloud,
xung quanh những dịch vụ mới sau đó đã xuất hiện.
Về cơ bản, đây là hai loại ủy quyền khác nhau. Ngoài ra, chúng tôi đã sử dụng một số phát triển Mail.ru riêng biệt, chẳng hạn như bộ lưu trữ mật khẩu chung của Mail.ru, cũng như trình kết nối openid tự viết, nhờ đó SSO (ủy quyền đầu cuối) đã được cung cấp trong bảng Horizon của máy ảo (UI OpenStack gốc).
Tạo IAM cho chúng tôi có nghĩa là kết nối tất cả vào một hệ thống duy nhất, hoàn toàn của riêng chúng tôi. Đồng thời, chúng tôi sẽ không mất bất kỳ chức năng nào trong quá trình thực hiện mà sẽ tạo nền tảng cho tương lai cho phép chúng tôi tinh chỉnh nó một cách minh bạch mà không cần tái cấu trúc và mở rộng quy mô về mặt chức năng. Cũng ngay từ đầu, người dùng đã có một hình mẫu để truy cập vào các dịch vụ (RBAC trung tâm, kiểm soát truy cập dựa trên vai trò) và một số điều nhỏ nhặt khác.
Nhiệm vụ hóa ra không hề đơn giản: python và Perl, một số chương trình phụ trợ, dịch vụ được viết độc lập, một số nhóm phát triển và quản trị viên. Và quan trọng nhất là có hàng nghìn người dùng trực tiếp trên hệ thống sản xuất chiến đấu. Tất cả điều này phải được viết ra và quan trọng nhất là được thực hiện mà không gây thương vong.
Chúng ta sẽ tung ra cái gì?
Nói một cách đại khái, trong khoảng 4 tháng, chúng tôi đã chuẩn bị những thứ sau:
- Chúng tôi đã tạo một số trình nền mới tổng hợp các chức năng trước đây hoạt động ở các phần khác nhau của cơ sở hạ tầng. Phần còn lại của dịch vụ được quy định một phần phụ trợ mới dưới hình dạng những con quỷ này.
- Chúng tôi đã viết kho lưu trữ mật khẩu và khóa trung tâm của riêng mình, có sẵn cho tất cả các dịch vụ của chúng tôi, có thể được sửa đổi tự do khi chúng tôi cần.
- Chúng tôi đã viết 4 chương trình phụ trợ mới cho Keystone từ đầu (người dùng, dự án, vai trò, phân công vai trò), trên thực tế, chương trình này đã thay thế cơ sở dữ liệu của Keystone và hiện hoạt động như một kho lưu trữ duy nhất cho mật khẩu người dùng của chúng tôi.
- Chúng tôi đã hướng dẫn tất cả các dịch vụ Openstack của mình chuyển sang dịch vụ chính sách của bên thứ ba để biết chính sách của họ thay vì đọc các chính sách này cục bộ từ mỗi máy chủ (vâng, đó là cách Openstack hoạt động theo mặc định!)
Việc làm lại lớn như vậy đòi hỏi những thay đổi lớn, phức tạp và quan trọng nhất là đồng bộ trong một số hệ thống được viết bởi các nhóm phát triển khác nhau. Sau khi lắp ráp, toàn bộ hệ thống sẽ hoạt động.
Làm thế nào để triển khai những thay đổi như vậy mà không làm hỏng nó? Đầu tiên chúng tôi quyết định nhìn về tương lai một chút.
Chiến lược triển khai
- Có thể tung ra sản phẩm theo nhiều giai đoạn, nhưng điều này sẽ làm tăng thời gian phát triển lên gấp ba lần. Ngoài ra, đôi khi chúng tôi sẽ không đồng bộ hóa hoàn toàn dữ liệu trong cơ sở dữ liệu. Bạn sẽ phải viết các công cụ đồng bộ hóa của riêng mình và sống với nhiều kho dữ liệu trong một thời gian dài. Và điều này tạo ra nhiều rủi ro khác nhau.
- Mọi thứ có thể được chuẩn bị một cách minh bạch cho người dùng đều đã được thực hiện trước. Phải mất 2 tháng.
- Chúng tôi đã cho phép mình ngừng hoạt động trong vài giờ - chỉ dành cho hoạt động của người dùng để tạo và thay đổi tài nguyên.
- Đối với hoạt động của tất cả các tài nguyên đã được tạo, thời gian ngừng hoạt động là không thể chấp nhận được. Chúng tôi đã lên kế hoạch rằng trong quá trình triển khai, các tài nguyên sẽ hoạt động mà không có thời gian ngừng hoạt động và ảnh hưởng đến khách hàng.
- Để giảm tác động đến khách hàng nếu có sự cố xảy ra, chúng tôi quyết định triển khai vào tối Chủ nhật. Ít khách hàng quản lý máy ảo vào ban đêm hơn.
- Chúng tôi đã cảnh báo tất cả khách hàng của mình rằng trong khoảng thời gian được chọn để triển khai, tính năng quản lý dịch vụ sẽ không khả dụng.
Lạc đề: triển khai là gì?
<thận trọng, triết lý>
Mọi chuyên gia CNTT đều có thể dễ dàng trả lời triển khai là gì. Bạn cài đặt CI/CD và mọi thứ sẽ tự động được gửi đến cửa hàng. 🙂
Tất nhiên điều này là đúng. Nhưng khó khăn là với các công cụ tự động phân phối mã hiện đại, sự hiểu biết về quá trình triển khai sẽ bị mất đi. Bạn làm sao quên đi sự vĩ đại của việc phát minh ra bánh xe khi nhìn vào phương tiện giao thông hiện đại. Mọi thứ đều được tự động hóa đến mức việc triển khai thường được thực hiện mà không hiểu được toàn cảnh.
Và toàn bộ bức tranh là như thế này. Triển khai bao gồm bốn khía cạnh chính:
- Cung cấp mã, bao gồm cả sửa đổi dữ liệu. Ví dụ, sự di cư của họ.
- Khôi phục mã là khả năng quay lại nếu có sự cố. Ví dụ, thông qua việc tạo bản sao lưu.
- Thời gian của mỗi hoạt động triển khai/khôi phục. Bạn cần hiểu thời gian của bất kỳ hoạt động nào của hai điểm đầu tiên.
- Chức năng bị ảnh hưởng. Cần phải đánh giá cả tác động tích cực dự kiến và tác động tiêu cực có thể xảy ra.
Tất cả những khía cạnh này phải được tính đến để triển khai thành công. Thông thường, chỉ có điểm đầu tiên hoặc tốt nhất là điểm thứ hai được đánh giá và sau đó quá trình triển khai được coi là thành công. Nhưng điều thứ ba và thứ tư thậm chí còn quan trọng hơn. Người dùng nào sẽ thích nếu quá trình triển khai mất 3 giờ thay vì một phút? Hoặc nếu có điều gì đó không cần thiết bị ảnh hưởng trong quá trình triển khai? Hay việc một dịch vụ ngừng hoạt động sẽ dẫn đến những hậu quả khó lường?
Màn 1..n, chuẩn bị phát hành
Lúc đầu, tôi nghĩ đến việc mô tả ngắn gọn các cuộc họp của chúng tôi: toàn đội, các bộ phận, hàng loạt cuộc thảo luận tại các điểm uống cà phê, tranh luận, kiểm tra, động não. Sau đó tôi nghĩ nó sẽ không cần thiết. Bốn tháng phát triển luôn bao gồm điều này, đặc biệt khi bạn không viết thứ gì đó có thể được cung cấp liên tục mà là một tính năng lớn cho một hệ thống trực tiếp. Điều này ảnh hưởng đến tất cả các dịch vụ nhưng không có gì thay đổi đối với người dùng ngoại trừ “một nút trong giao diện web”.
Sự hiểu biết của chúng tôi về cách triển khai đã thay đổi đáng kể sau mỗi cuộc họp mới. Ví dụ: chúng tôi sẽ cập nhật toàn bộ cơ sở dữ liệu thanh toán của mình. Nhưng chúng tôi đã tính toán thời gian và nhận ra rằng không thể thực hiện được điều này trong thời gian triển khai hợp lý. Chúng tôi mất thêm gần một tuần để phân chia và lưu trữ cơ sở dữ liệu thanh toán. Và khi tốc độ triển khai dự kiến vẫn chưa đạt yêu cầu, chúng tôi đã đặt hàng phần cứng bổ sung, mạnh hơn, trong đó toàn bộ phần đế được kéo theo. Không phải là chúng tôi không muốn làm điều này sớm hơn, nhưng nhu cầu triển khai hiện tại khiến chúng tôi không còn lựa chọn nào khác.
Khi một người trong chúng tôi nghi ngờ rằng việc triển khai có thể ảnh hưởng đến tính khả dụng của máy ảo của chúng tôi, chúng tôi đã dành một tuần để tiến hành các thử nghiệm, thử nghiệm, phân tích mã và nhận được sự hiểu biết rõ ràng rằng điều này sẽ không xảy ra trong quá trình sản xuất của chúng tôi và ngay cả những người nghi ngờ nhất cũng đồng ý Với cái này.
Trong khi đó, những người ở bộ phận hỗ trợ kỹ thuật đã tiến hành các thử nghiệm độc lập của riêng họ để viết hướng dẫn cho khách hàng về các phương thức kết nối dự kiến sẽ thay đổi sau khi triển khai. Họ làm việc trên UX của người dùng, chuẩn bị hướng dẫn và cung cấp tư vấn cá nhân.
Chúng tôi đã tự động hóa tất cả các hoạt động triển khai có thể thực hiện được. Mọi thao tác đều được viết kịch bản, ngay cả những thao tác đơn giản nhất và các bài kiểm tra được chạy liên tục. Họ tranh luận về cách tốt nhất để tắt dịch vụ - bỏ qua daemon hoặc chặn quyền truy cập vào dịch vụ bằng tường lửa. Chúng tôi đã tạo danh sách kiểm tra các nhóm cho từng giai đoạn triển khai và cập nhật danh sách đó liên tục. Chúng tôi đã vẽ và liên tục cập nhật biểu đồ Gantt cho tất cả công việc triển khai kèm theo thời gian.
Và vì thế…
Màn cuối cùng trước khi ra mắt
...đã đến lúc ra mắt.
Như người ta thường nói, một tác phẩm nghệ thuật không thể hoàn thành, chỉ có công việc hoàn thành nó mới hoàn thành. Bạn phải nỗ lực hết mình, hiểu rằng bạn sẽ không tìm thấy mọi thứ, nhưng tin rằng bạn đã đưa ra mọi giả định hợp lý, dự phòng mọi trường hợp có thể xảy ra, đóng tất cả các lỗi nghiêm trọng và tất cả những người tham gia đã làm mọi thứ họ có thể. Càng tung ra nhiều mã, bạn càng khó thuyết phục bản thân về điều này (hơn nữa, mọi người đều hiểu rằng không thể thấy trước mọi thứ).
Chúng tôi quyết định rằng chúng tôi sẵn sàng triển khai khi tin chắc rằng chúng tôi đã làm mọi thứ có thể để giải quyết mọi rủi ro cho người dùng liên quan đến những ảnh hưởng và thời gian ngừng hoạt động không mong muốn. Nghĩa là, bất cứ điều gì cũng có thể xảy ra ngoại trừ:
- Ảnh hưởng đến cơ sở hạ tầng người dùng (linh thiêng, quý giá nhất đối với chúng tôi),
- Chức năng: việc sử dụng dịch vụ của chúng tôi sau khi triển khai phải giống như trước đó.
Lăn ra
Hai cuộn, 8 không can thiệp
Chúng tôi dành thời gian ngừng hoạt động cho tất cả các yêu cầu từ người dùng trong 7 giờ. Tại thời điểm này, chúng tôi có cả kế hoạch triển khai và kế hoạch khôi phục.
- Quá trình triển khai mất khoảng 3 giờ.
- 2 giờ để kiểm tra.
- 2 giờ - dự trữ cho khả năng khôi phục các thay đổi.
Một biểu đồ Gantt đã được vẽ ra cho từng hành động, mất bao lâu, những gì diễn ra tuần tự, những gì được thực hiện song song.
Một phần của biểu đồ Gantt triển khai, một trong những phiên bản đầu tiên (không thực thi song song). Công cụ đồng bộ hóa có giá trị nhất
Tất cả những người tham gia đều có vai trò được xác định trong quá trình triển khai, nhiệm vụ họ làm và trách nhiệm của họ. Chúng tôi cố gắng đưa từng giai đoạn về trạng thái tự động, triển khai, triển khai lại, thu thập phản hồi và triển khai lại.
Biên niên sự kiện
Vậy có 15 người đến làm việc vào Chủ nhật ngày 29 tháng 10 lúc XNUMX giờ tối. Ngoài những người tham gia chính, một số người đến chỉ để hỗ trợ nhóm và họ đặc biệt cảm ơn họ.
Điều đáng nói là người thử nghiệm chính của chúng tôi đang trong kỳ nghỉ. Không thể triển khai nếu không thử nghiệm, chúng tôi đang khám phá các lựa chọn. Một đồng nghiệp đồng ý kiểm tra chúng tôi sau kỳ nghỉ, điều này khiến cô ấy nhận được lòng biết ơn sâu sắc từ toàn đội.
00:00. Dừng lại
Chúng tôi dừng yêu cầu của người dùng, treo biển báo công việc kỹ thuật. Giám sát hét lên, nhưng mọi thứ vẫn bình thường. Chúng tôi kiểm tra xem không có gì rơi ngoài những gì được cho là rơi. Và chúng tôi bắt đầu công việc di chuyển.
Mọi người đều có bản in kế hoạch triển khai từng điểm một, mọi người đều biết ai đang làm gì và vào thời điểm nào. Sau mỗi hành động, chúng tôi kiểm tra thời gian để đảm bảo không vượt quá chúng và mọi thứ diễn ra theo đúng kế hoạch. Những người không trực tiếp tham gia triển khai ở giai đoạn hiện tại đang chuẩn bị tung ra một món đồ chơi trực tuyến (Xonotic, quacks loại 3) để không làm phiền đồng nghiệp của họ. 🙂
02:00. Lăn ra
Một điều ngạc nhiên thú vị - chúng tôi kết thúc quá trình triển khai sớm hơn một giờ do việc tối ưu hóa cơ sở dữ liệu và tập lệnh di chuyển của chúng tôi. Tiếng kêu chung, "lăn ra!" Tất cả các chức năng mới đều đang được sản xuất nhưng cho đến nay chỉ chúng ta mới có thể nhìn thấy chúng trong giao diện. Mọi người chuyển sang chế độ thử nghiệm, sắp xếp chúng thành các nhóm và bắt đầu xem cuối cùng điều gì đã xảy ra.
Mọi chuyện diễn ra không được tốt lắm, chúng tôi nhận ra điều này sau 10 phút, khi không có gì được kết nối hoặc làm việc trong các dự án của các thành viên trong nhóm. Đồng bộ hóa nhanh chóng, chúng tôi nêu lên vấn đề của mình, đặt mức độ ưu tiên, chia thành các nhóm và tiến hành gỡ lỗi.
02:30. Hai vấn đề lớn vs bốn mắt
Chúng tôi tìm thấy hai vấn đề lớn. Chúng tôi nhận thấy rằng khách hàng sẽ không thấy một số dịch vụ được kết nối và các vấn đề sẽ phát sinh với tài khoản đối tác. Cả hai đều là do tập lệnh di chuyển không hoàn hảo đối với một số trường hợp khó khăn. Chúng ta cần phải sửa nó ngay bây giờ.
Chúng tôi viết các truy vấn ghi lại điều này, với ít nhất 4 mắt. Chúng tôi kiểm tra chúng trong quá trình tiền sản xuất để đảm bảo chúng hoạt động và không làm hỏng bất cứ thứ gì. Bạn có thể lăn tiếp. Đồng thời, chúng tôi tiến hành thử nghiệm tích hợp thường xuyên và phát hiện thêm một số vấn đề. Chúng đều nhỏ nhưng cũng cần được sửa chữa.
03:00. -2 vấn đề +2 vấn đề
Hai vấn đề lớn trước đó đã được khắc phục và gần như tất cả những vấn đề nhỏ cũng vậy. Tất cả những người chưa có bản sửa lỗi đều đang tích cực làm việc trong tài khoản của họ và báo cáo những gì họ tìm thấy. Chúng tôi ưu tiên, phân bổ giữa các nhóm và để lại những mục không quan trọng cho buổi sáng.
Chúng tôi chạy thử nghiệm lại, họ phát hiện ra hai vấn đề lớn mới. Không phải tất cả các chính sách dịch vụ đều được gửi chính xác nên một số yêu cầu của người dùng không được ủy quyền. Cộng với một vấn đề mới với tài khoản đối tác. Chúng ta hãy vội vàng nhìn xem.
03:20. Đồng bộ hóa khẩn cấp
Một vấn đề mới đã được khắc phục. Lần thứ hai, chúng tôi đang tổ chức đồng bộ hóa khẩn cấp. Chúng tôi hiểu điều gì đang xảy ra: bản sửa lỗi trước đã khắc phục được một sự cố nhưng lại tạo ra một sự cố khác. Chúng tôi nghỉ ngơi để tìm ra cách thực hiện nó một cách chính xác và không có hậu quả.
03:30. Sáu mắt
Chúng tôi hiểu trạng thái cuối cùng của cơ sở là gì để mọi thứ diễn ra tốt đẹp cho tất cả các đối tác. Chúng tôi viết yêu cầu với 6 mắt, triển khai ở giai đoạn tiền sản xuất, thử nghiệm và đưa vào sản xuất.
04:00. Mọi thứ đang hoạt động
Tất cả các bài kiểm tra đã vượt qua, không có vấn đề nghiêm trọng nào được nhìn thấy. Đôi khi, có điều gì đó trong nhóm không phù hợp với ai đó, chúng tôi sẽ phản ứng kịp thời. Thông thường, báo động là sai. Nhưng đôi khi nội dung nào đó không đến hoặc một trang riêng không hoạt động. Chúng tôi ngồi, sửa, sửa, sửa. Một nhóm riêng biệt đang triển khai tính năng lớn cuối cùng - thanh toán.
04:30. Điểm không thể quay lại
Điểm không thể quay lại đang đến gần, tức là thời điểm mà nếu chúng ta bắt đầu quay trở lại, chúng ta sẽ không đáp ứng được thời gian ngừng hoạt động được giao cho mình. Có vấn đề với việc thanh toán, vốn biết và ghi lại mọi thứ nhưng lại ngoan cố từ chối xóa tiền của khách hàng. Có một số lỗi trên từng trang, hành động và trạng thái. Chức năng chính hoạt động, tất cả các bài kiểm tra đều vượt qua thành công. Chúng tôi quyết định rằng việc triển khai đã diễn ra, chúng tôi sẽ không quay trở lại.
06:00. Mở cho mọi người trong giao diện người dùng
Lỗi cố định. Một số thứ không hấp dẫn người dùng sẽ được để lại sau. Chúng tôi mở giao diện cho mọi người. Chúng tôi tiếp tục làm việc về thanh toán, chờ phản hồi của người dùng và theo dõi kết quả.
07:00. Sự cố khi tải API
Rõ ràng là chúng tôi đã lập kế hoạch sai một chút cho việc tải API của mình và đã kiểm tra tải này nhưng không thể xác định được sự cố. Kết quả là ≈5% yêu cầu không thành công. Hãy vận động và tìm hiểu nguyên nhân.
Thanh toán cứng đầu và cũng không muốn làm việc. Chúng tôi quyết định hoãn lại cho đến sau này để thực hiện những thay đổi một cách bình tĩnh. Có nghĩa là, tất cả các nguồn lực đều được tích lũy trong đó, nhưng việc xóa nợ từ khách hàng sẽ không được thực hiện. Tất nhiên, đây là một vấn đề, nhưng so với việc triển khai chung thì nó có vẻ không quan trọng.
08:00. Sửa API
Chúng tôi đã đưa ra bản sửa lỗi cho tải, lỗi đã biến mất. Chúng tôi bắt đầu về nhà.
10:00. Tất cả
Mọi thứ đã được sửa. Im lặng giám sát và đến chỗ khách hàng, cả nhóm dần chìm vào giấc ngủ. Việc thanh toán vẫn còn, chúng tôi sẽ khôi phục lại vào ngày mai.
Sau đó, trong ngày, chúng tôi đã triển khai các bản sửa lỗi nhật ký, thông báo, mã trả lại và các tùy chỉnh cho một số khách hàng của chúng tôi.
Vậy là đợt triển khai đã thành công! Tất nhiên, nó có thể tốt hơn, nhưng chúng tôi đã rút ra kết luận về những gì chưa đủ để chúng tôi đạt được sự hoàn hảo.
trong tổng số
Trong 2 tháng tích cực chuẩn bị triển khai, 43 nhiệm vụ đã được hoàn thành, kéo dài từ vài giờ đến vài ngày.
Trong quá trình triển khai:
- quỷ mới và thay đổi - 5 mảnh, thay thế 2 khối nguyên khối;
- những thay đổi trong cơ sở dữ liệu - tất cả 6 cơ sở dữ liệu có dữ liệu người dùng của chúng tôi đã bị ảnh hưởng, việc tải xuống đã được thực hiện từ ba cơ sở dữ liệu cũ sang một cơ sở dữ liệu mới;
- giao diện người dùng được thiết kế lại hoàn toàn;
- số lượng mã được tải xuống - 33 nghìn dòng mã mới, ≈ 3 nghìn dòng mã trong thử nghiệm, ≈ 5 nghìn dòng mã di chuyển;
- tất cả dữ liệu còn nguyên vẹn, không một máy ảo nào của khách hàng bị hỏng. 🙂
Các phương pháp hay để triển khai hiệu quả
Họ đã hướng dẫn chúng tôi trong hoàn cảnh khó khăn này. Tuy nhiên, nói chung, sẽ rất hữu ích khi theo dõi chúng trong bất kỳ đợt triển khai nào. Nhưng việc triển khai càng phức tạp thì vai trò của chúng càng lớn.
- Điều đầu tiên bạn cần làm là hiểu việc triển khai có thể hoặc sẽ ảnh hưởng đến người dùng như thế nào. Sẽ có thời gian ngừng hoạt động? Nếu vậy, thời gian ngừng hoạt động là gì? Điều này sẽ ảnh hưởng đến người dùng như thế nào? Các tình huống tốt nhất và xấu nhất có thể xảy ra là gì? Và che chắn những rủi ro.
- Lập kế hoạch mọi thứ. Ở mỗi giai đoạn, bạn cần hiểu tất cả các khía cạnh của quá trình triển khai:
- giao mã;
- khôi phục mã;
- thời gian của mỗi thao tác;
- chức năng bị ảnh hưởng.
- Xem qua các kịch bản cho đến khi tất cả các giai đoạn triển khai cũng như rủi ro ở mỗi giai đoạn đó trở nên rõ ràng. Nếu bạn có bất kỳ nghi ngờ nào, bạn có thể nghỉ ngơi và kiểm tra riêng giai đoạn nghi vấn.
- Mỗi giai đoạn có thể và nên được cải thiện nếu nó giúp ích cho người dùng của chúng tôi. Ví dụ, nó sẽ giảm thời gian ngừng hoạt động hoặc loại bỏ một số rủi ro.
- Kiểm tra khôi phục quan trọng hơn nhiều so với kiểm tra phân phối mã. Cần phải kiểm tra xem do quá trình khôi phục, hệ thống có trở lại trạng thái ban đầu hay không và xác nhận điều này bằng các thử nghiệm.
- Mọi thứ có thể tự động hóa đều phải được tự động hóa. Mọi thứ không thể tự động hóa nên được viết trước trên một bảng ghi chú.
- Ghi lại tiêu chí thành công. Chức năng nào sẽ có sẵn và vào thời điểm nào? Nếu điều này không xảy ra, hãy chạy một kế hoạch khôi phục.
- Và quan trọng nhất - con người. Mọi người nên biết họ đang làm gì, tại sao và điều gì phụ thuộc vào hành động của họ trong quá trình triển khai.
Và chỉ trong một câu, với việc lập kế hoạch và xây dựng tốt, bạn có thể đưa ra bất cứ điều gì bạn muốn mà không ảnh hưởng đến doanh số bán hàng. Thậm chí có điều gì đó sẽ ảnh hưởng đến tất cả các dịch vụ của bạn trong quá trình sản xuất.
Nguồn: www.habr.com