Hiểu vấn đề khi mọi thứ vỡ trong sản xuất

Kịch bản:

• Bạn đẩy đến sản xuất
• Sự thúc đẩy đã phá vỡ nhiều thứ
• Bản dựng đó không phá vỡ qa hay dev
• Là một nhà phát triển, bạn không có quyền truy cập prod.
• Có rất nhiều áp lực từ phía trên để có được những thứ làm việc nhanh nhẹn.

Cụ thể:

• Ứng dụng PHP / MVC được điều khiển API trong Zend.
• Đã triển khai đến một vài máy chủ.

Câu hỏi của tôi:

Trong khi điều tra, hãy nói rằng tôi có linh cảm rằng có điều gì đó không ổn. Nhưng, tôi không biết chắc chắn. Và, tất nhiên, tôi không thể kiểm tra mọi thứ trong sản xuất. Nếu tôi có một sửa chữa được đề xuất dựa trên linh cảm đó, liệu có nên khôn ngoan khi thử và áp dụng nó và xem nó có hoạt động không, trước khi hiểu vấn đề là gì?

Lấy càng nhiều thông tin về vấn đề càng tốt (logfiles, v.v.) và sau đó đưa các máy chủ sản xuất về trạng thái hoạt động. Đó là một nỗi đau từ quan điểm của nhà phát triển tất nhiên, nhưng rất có thể là một cho trước.

Tiếp theo, hãy thử và xem liệu bạn có thể tái tạo vấn đề trong môi trường phát triển hay không. Nếu bạn có thể, sau đó sửa nó và thử phát hành lại.

Nếu bạn không thể tái tạo nó, hãy xem liệu bạn có thể thêm chẩn đoán và phát hành cho một máy chủ trong một thời gian ngắn để có thêm thông tin về sự cố không.

Nếu điều đó là không thể thì hãy xem xét kỹ hơn sự khác biệt giữa môi trường sản xuất và môi trường dev / qa và cố gắng tạo môi trường dev gần hơn với sản xuất.

Làm thế nào cũng làm bạn hiểu được vấn đề? Rủi ro mà linh cảm của bạn sẽ làm mọi thứ tồi tệ hơn là gì? Có thể quay lại và tái tạo vấn đề trong các vùng DEV / QA không? Bạn có thể làm gì để đồng bộ hóa vùng DEV / QA của mình để đến gần hơn với SẢN PHẨM? Có thể bạn phải thay đổi một số cài đặt môi trường hoặc cơ sở dữ liệu, có thể bạn phải nhập dữ liệu SẢN PHẨM sang DEV, có thể bạn phải thay đổi một số cài đặt gỡ lỗi.

Nói chung, tôi không khuyên bạn nên đẩy linh cảm của mình về một giải pháp cho sản xuất trừ khi bạn có thể xác nhận rằng nó thực sự đúng ở một khu vực khác. Tôi hiểu loại sự cố phát sinh khi có lỗi xảy ra trong SẢN PHẨM và không thể được sao chép ở bất kỳ nơi nào khác. Đó là khi bắt đầu thấy những gì khác biệt giữa DEV / QA và SẢN PHẨM và tập trung vào những thứ đó. Theo kinh nghiệm của tôi, đó thường là cài đặt môi trường hoặc một số cấu hình khác, đặc biệt dành cho SẢN PHẨM. Và tôi biết rằng có lẽ có rất nhiều áp lực từ phía trên để khắc phục điều này, vì vậy có thể quay trở lại trạng thái làm việc trước đó và sau đó thử tái tạo vấn đề trong DEV, đưa ra cách khắc phục trong DEV, sau đó thử lại sản xuất? Đó là những gì tôi muốn đề xuất.

Phụ thuộc vào loại sửa chữa. Thường xuyên hơn không, các vấn đề trong sản xuất không xuất hiện trong dev có liên quan đến tranh cãi trong cơ sở dữ liệu. Vì vậy, áp dụng một lỗi làm thay đổi nội dung cơ sở dữ liệu mà không chắc chắn chính xác "ngoài kia" có thể là bước đầu tiên trong một thảm họa lớn. Nếu bạn có thể dễ dàng lấy lại sự thay đổi, bạn có thể thử lại. Nhưng nói chung, nếu bạn không có quyền truy cập trực tiếp, ít nhất nên có một bản sao của cơ sở dữ liệu hoặc toàn bộ máy chủ để kiểm tra. Những người có đặc quyền phù hợp vẫn sẽ phải chạy mã mới, nhưng ít nhất không có nguy cơ mất dữ liệu. (Nhưng đôi khi kích thước của cơ sở dữ liệu hoặc độ phức tạp của cơ sở hạ tầng cấm thiết lập như vậy)

Điều đó thực sự khó khăn, vì có nhiều khả năng như các cài đặt, thư viện và phiên bản phần mềm khác nhau.

Có thể trước tiên bạn có thể viết một đoạn mã để đánh giá với một số đầu ra gỡ lỗi nếu bạn đoán nguồn gốc của lỗi là đúng và chỉ sau đó áp dụng lỗi thực tế.

Thông thường, đó là vấn đề về cấu hình hoặc dữ liệu, giả sử rằng mã và DB giống hệt nhau giữa Prod, QA và dev.

Trước tiên tôi sẽ xem xét như sau:

• Bất kỳ dữ liệu đăng nhập mã của bạn có.
• Kiểm tra người xem sự kiện cho các ngoại lệ chưa được xử lý.
• Kiểm tra dữ liệu đại diện cho tiến trình của ứng dụng của bạn, nó có thể nằm trong DB, tệp, v.v. Nó có ý nghĩa hay không? Là những gì bạn mong đợi?

Khi bạn hiểu điều gì đang xảy ra, bạn cần chuyển sản xuất về trạng thái làm việc và khắc phục sự cố trong môi trường thấp hơn, cho đến khi sửa và triển khai lại vào sản xuất.

Trong khi môi trường của bạn là PHP, tôi đã trình bày về cách nghĩ về nó cho Java: http://www.infoq.com/presentations/maintained-production-java-apps

Các vấn đề cốt lõi là như nhau - để hiểu các điểm nghẹt có thể xảy ra để khắc phục sự cố: mạng, truy cập hệ thống tệp, tệp nhật ký, khóa chết, v.v. Ngoài ra, để biết cách đặt câu hỏi đúng: "Hệ thống bị lỗi" có nghĩa là: trang web có chậm không, có thông báo lỗi cụ thể không, có thời gian chờ không ", v.v.

Ngoài ra, có một số công cụ giúp xử lý sự cố dễ dàng hơn: Wireshark để khắc phục sự cố mạng là cách tốt nhất tuyệt đối và đáng để học hỏi. Những người khác phụ thuộc vào O / S bạn sử dụng. Đối với Windows, mọi thứ từ SysI Internalal (hiện là một phần của Microsoft) đều tuyệt vời. Đối với Unix / Linux, hãy xem kèo / strace.

Khi truy cập vào sản xuất, nhóm hoạt động nên biết cách sử dụng các công cụ / kỹ thuật đó hoặc bạn có một trường hợp kinh doanh cho họ (cùng với bạn) để tìm hiểu cách sử dụng chúng. Sau đó, họ cần một bộ giao thức khắc phục sự cố cụ thể để chạy khi có sự cố xảy ra, do đó bạn có thể thực hiện phân tích ngoại tuyến.

Câu trả lời ngắn: Không nếu bạn có một sự lựa chọn.

Câu trả lời dài: Nếu bạn không hiểu vấn đề, có một số rủi ro liên quan đến một bản vá như vậy:

1. Bạn có thể phá vỡ một cái gì đó khác, mà thậm chí có thể tái sản xuất ít hơn.
2. Bạn chỉ có thể che giấu vấn đề, làm cho việc chú ý và tái tạo trở nên khó khăn hơn (điều này làm cho nó tồi tệ hơn)
3. Bạn đang vứt bỏ kinh nghiệm trong nước tiềm năng - kinh nghiệm có thể giúp bạn trở thành một lập trình viên tốt hơn, đồng thời có giá trị hơn cho công ty của bạn (tức là tăng lương tiềm năng trong tương lai).

Mặt khác, tôi thấy không có hại gì trong lần kiểm tra đầu tiên nếu cách khắc phục giả thuyết của bạn có hiệu quả không, và nếu có - thì hãy đào sâu hơn và tìm hiểu lý do thực sự hoặc các cách khác có thể tốt hơn để giải quyết vấn đề.