Làm thế nào để bạn giữ mát khi hệ thống sản xuất đi xuống? [đóng cửa]


26

Điều này đã xảy ra với hầu hết chúng ta ...

Bạn đến làm việc một ngày. Mọi thứ dường như bình thường - mặt trời đang chiếu sáng, những con chim đang hót líu lo, nhưng bạn nhận thấy một vài điều kỳ lạ trên đường đi làm khiến bạn nhớ đến con mèo déjà vu trong Ma trận.

Bạn vào văn phòng và có rất nhiều điện thoại reo - nhưng có thể là họ đang thực hiện một chương trình khuyến mại mới. Bạn ổn định, khi bạn nhận thấy một đám mây đen lơ lửng trên bạn.

Bạn sẽ mất một vài khoảnh khắc, nhưng bạn nhận ra đám mây là ông chủ của mình. Thường thì anh ấy kiểm tra bạn mỗi sáng với "Soooo Peeeeter, làm thế nào về những báo cáo TCP / IP đó?" thường lệ, nhưng hôm nay anh ta quên mọi thứ về cách cư xử thông thường và xâm chiếm thô lỗ không gian cá nhân của bạn. Không có "Chào buổi sáng", chỉ có vài tiếng chảy nước dãi, càu nhàu và chửi rủa. Anh ấy nhắc nhở bạn một chút về một người Neanderthal đang cố gắng thoát khỏi một con hổ đứng trên mạng, sợ hãi và hoảng loạn tất cả bị nén trong một quả bóng chặt chẽ. Bạn cố gắng giải mã ngôn ngữ mới mà anh ấy tạo ra từ hôm qua và bạn bắt đầu hiểu rằng có điều gì đó tồi tệ đã xảy ra chỉ sau một đêm - hệ thống sản xuất bị hỏng.

Giờ đây, hệ thống của bạn thường được khách hàng sử dụng trong giờ làm việc thông thường từ 9-5, nhưng vì bất kỳ lý do gì bạn không nhận được bất kỳ cảnh báo nào về tiếng bíp của mình (đối với những người dưới 30 tuổi - tiếng bíp giống như điện thoại di động chỉ có thể đổ chuông và cho bạn biết ai đã bíp bạn). Bạn sẽ cần phải nhớ sạc lần sau.

Vì vậy, bây giờ là 8:45 sáng và hệ thống PHẢI hoạt động lúc 9 giờ sáng. Cứ sau 10 giây, sếp của bạn lại đưa ra một lời nguyền khác truyền đến bạn rằng một khách hàng khác đang gặp vấn đề khi xâm nhập vào hệ thống. Ngoài ra, một số người quản lý tài khoản hiện đang lơ lửng trên sếp của bạn đang cố gắng làm cho anh ta hiểu khách hàng thực sự đau khổ như thế nào.

Mọi người đều phụ thuộc vào bạn để đưa hệ thống lên càng sớm càng tốt và đồng thời đang cản trở tiến trình của bạn bằng cách liên tục làm bạn mất tập trung.

Làm thế nào để bạn giữ mát trong một tình huống như thế này?


34
Bước một: Soạn một bài đăng 300 từ trên lập trình viên.stackexchange.
kubi

8
Không nói rằng nó đang xảy ra ngay bây giờ. Đợi tôi kiểm tra ...
Mag20

1
Đây có phải là một vấn đề duy nhất cho các nhà phát triển? Nếu thứ gì đó bạn chịu trách nhiệm không hoạt động, bạn cần có khả năng đối phó với áp lực bất kể "thứ đó" là gì.
ChrisF

1
Tôi đã thấy rằng theo kinh nghiệm của riêng tôi, rất ít nhà phần mềm, lớn và nhỏ thực hiện bất kỳ cuộc tập trận khắc phục thảm họa nào. Tôi sẽ đưa nó cho ông chủ của bạn. Nếu những điều bạn làm một mũi khoan, thì bạn biết những gì mong đợi và bạn biết có thể cảm nhận được thời gian phản hồi. Bạn cũng có thể đánh giá nếu bất kỳ quá trình có thể được tự động. Điều gì xảy ra nếu bạn mất điện? Điều gì xảy ra nếu một đám cháy bắt đầu trong văn phòng, bạn có một vị trí bên ngoài? Các máy chủ của bạn được lưu trữ trong nhà hay bên ngoài, v.v ... Thực sự, bạn cần nhấn mạnh để đưa ra một kế hoạch chống đối.
Hành tinh hoang vắng

3
Điều này đọc giống như bắt đầu của một mục trên TheD DailyWTF!
Cấp Palin

Câu trả lời:


43

Trong tình huống, hãy yêu cầu sếp của bạn giúp đỡ bạn bằng cách giữ tất cả những người khác tránh xa bạn (điều này mang lại cho anh ta điều gì đó để làm ở một nơi khác).

Khi bạn nhận được nó và chạy lại, hãy yêu cầu sếp của bạn cho một cuộc họp để đánh giá và thiết lập các thủ tục để tránh điều này xảy ra lần nữa.


1
+1. Diễn tập khắc phục thảm họa là cách tốt để đánh giá phản ứng và thời gian phản hồi. Thật xấu hổ tôi không thấy đủ của nó được thực hiện.
Hành tinh hoang vắng

@DP yah, nhưng chúng tôi không thể làm điều đó bởi vì điều đó có nghĩa là con người và thiết bị không có sẵn cho các trường hợp khẩn cấp thực tế trong khi cuộc tập trận đang diễn ra (vâng, tôi đã nghe cuộc tranh luận đó nhiều lần). Tất nhiên, nếu có đủ người và thiết bị, bạn có thể huấn luyện một đội trên một bộ trong khi nhóm kia đang làm nhiệm vụ ...
jwenting

@jwenting âm thanh như tiết kiệm trên báo cháy.

9

Điều đầu tiên cần làm là loại bỏ những phiền nhiễu một cách lịch sự nhất có thể. Không ai có thể làm việc với ai đó đắm đuối trong tai bạn về việc nó tệ như thế nào đối với khách hàng của bạn. Điều này tất nhiên nói dễ hơn làm nếu sếp của bạn là một kẻ điên, nhưng nếu đó là trường hợp, bạn có thể muốn xem xét việc tìm một công việc khác nào.

Sau đó thực hiện đánh giá nhanh về tổn thất thực sự mà lỗi gây ra và làm thế nào (nếu có) nó có thể được giảm thiểu nhanh chóng. Với một chút luyện tập, bạn cũng có thể kiểm tra nhanh các tệp nhật ký, mà bạn sẽ cần phải lập một kế hoạch hành động.

Nếu vấn đề phức tạp, hãy tập trung vào phần nghiêm trọng nhất của nó. Hãy suy nghĩ hai hoặc ba bước trước khi bạn nhảy vào hành động. Ngoài ra, hãy chắc chắn rằng bạn biết cách rút lui khỏi bất kỳ kế hoạch nào trước khi hành động.

Và điều quan trọng nhất: Đừng hoảng sợ!


7

Tình huống như thế này là phổ biến trong các hệ thống điều khiển công nghiệp. Dây chuyền sản xuất ngừng hoạt động vào giữa đêm, công ty thường mất hàng trăm, thậm chí hàng nghìn đô la mỗi phút và họ đang nhìn bạn để khắc phục vấn đề. Bạn xử lý nó như vậy:

  1. Giải thích cho họ những gì bạn biết
  2. Giải thích những gì bạn không biết (nhưng cần biết để giải quyết vấn đề)
  3. Giải thích cách bạn sẽ tìm hiểu những gì bạn không biết
  4. Cung cấp cho họ ước tính thời gian sẽ mất bao lâu (sử dụng một phạm vi)
  5. Bỏ qua mọi thứ xung quanh bạn trong khi bạn tập trung làm theo kế hoạch của mình

6

Điều đầu tiên là phải liên tục thực hành khắc phục thảm họa (không có người đứng trên vai bạn) để bạn biết chính xác những bước bạn cần thực hiện để chẩn đoán và khắc phục sự cố mà không phải dùng đến câu hỏi trên SO để tìm hiểu phải làm gì. Một khi bạn cảm thấy tự tin vào các kỹ năng phục hồi của mình, áp lực và căng thẳng sẽ thấp hơn nhiều.

Tiếp theo là lấy người ra khỏi tóc trong khi bạn làm việc. Sếp của bạn muốn một cái gì đó anh ta có thể đi đến ông chủ của mình với. Cung cấp cho họ một số thông tin về những gì bạn dự định làm và mất bao lâu để làm và sau đó báo cáo tiến độ thường xuyên, đặc biệt nếu bạn tìm thấy điều gì đó có nghĩa là sẽ mất nhiều thời gian hơn bạn đã nói với họ. Có báo cáo tiến độ mất nhiều thời gian để sửa nó, nhưng các ông chủ và người dùng lơ lửng thậm chí còn mất nhiều thời gian hơn. Tôi, tôi đi cho các báo cáo tiến độ mỗi lần. Một khi họ tự tin rằng bạn sẽ giữ họ cập nhật, họ sẽ tin tưởng bạn làm công việc của bạn nhiều hơn và để bạn một mình nhiều hơn.

Nếu người dùng sẽ bị chặn một thời gian, sau đó gửi email cho họ nếu đây là một tùy chọn hoặc đưa ra thông báo trên trang web, nói rằng trang web không hoạt động để bảo trì và khi nào họ có thể thử lại. (Đây có thể là một nhiệm vụ bạn có thể giao cho sếp của mình để tìm ai đó làm để tránh cho anh ta khỏi tóc của bạn.) Mọi người sẽ bớt cáu kỉnh về việc không thể đăng nhập khi họ biết ai đó đang giải quyết vấn đề. Khi mọi thứ đã được sửa, nếu bạn đã gửi một email, hãy gửi email cho cùng một nhóm để nói với họ rằng nó đã được sửa. Không thể cho bạn biết bao nhiêu lần tôi thấy mọi người quên điều này và người dùng vẫn nghĩ rằng họ không thể đăng nhập khi có thể. Mục tiêu không chỉ là làm cho mọi thứ trở nên tốt hơn mà là để mọi người làm việc với hệ thống một lần nữa.

Hít thở sâu (hơi thở sâu đang nguôi) và lao vào vấn đề. Thật tốt khi có những điều bạn cần viết ra ở đâu đó vì trong trường hợp khẩn cấp đôi khi các khớp thần kinh của bạn không lấy được thông tin nhanh như bình thường. Bạn không muốn trông giống như một thằng ngốc lẩm bẩm: "Tôi biết chúng ta có một khúc gỗ, nó ở đâu vậy?"

Nếu bạn đang ở trong một công việc mà bạn hỗ trợ các hệ thống sản xuất, tốt nhất nên là loại người phản ứng tốt trong trường hợp khẩn cấp nói chung. Tôi không chắc bạn có thể học điều này thực sự. Nếu ai đó cưỡi ngựa trước mặt bạn ngã xuống (một ví dụ không ngẫu nhiên lấy từ cuộc đời tôi) và đang nằm chảy máu trên mặt đất, bạn có phải là người đứng đó với cái miệng há hốc hay là người Ai gọi xe cứu thương, băng bó áp lực lên máu và chỉ đạo ai đó bắt ngựa? Nếu bạn là kiểu người đầu tiên, có lẽ đây không phải là dòng công việc phù hợp với bạn.


2

Nói với họ đây là một lý do chính đáng tại sao bạn cần một máy chủ dự phòng, và ý tôi là máy chủ thứ hai chạy giống như máy chủ chính có thể được chuyển sang ngay lập tức nếu máy chủ đầu tiên bị hỏng.


Tôi đã thấy một máy chủ dự phòng được bật và nó có cùng một vấn đề với máy chủ chính. Nó tăng gấp đôi chi phí phần cứng, thêm vào chi phí cấu hình và là một sự lãng phí tổng chi phí. Nếu bạn đang làm công việc có tính sẵn sàng cao, thì chắc chắn, nhưng bạn phải đặt đúng kích thước phần cứng của mình cho vấn đề.
Scott Whitlock

một ví dụ (cực kỳ) về hệ thống dự phòng bị ảnh hưởng bởi lỗi tương tự như hệ thống chính là Ariane 5 Chuyến bay 501
Andre Holzner

2

Nó đủ tệ khi bạn bị bao vây từ mọi phía bởi những người tức giận với bạn vì một vấn đề bạn tạo ra, mặc dù nó tệ gấp đôi khi đó là vấn đề bạn không tạo ra. Điều đó đã xảy ra với tôi hơn một lần rằng khách hàng đã cấu hình nó không tốt, có nghĩa là lỗi là do giao tiếp với khách hàng (cho dù lỗi là do khách hàng không lắng nghe hay nhà tiếp thị không giải thích rõ, bạn sẽ không bao giờ biết).

Làm thế nào để bạn giải thích rằng họ sai lầm? Không bao giờ là một nhiệm vụ dễ dàng, đặc biệt là khi sếp của bạn đang thở dốc vì bạn không biết gì hơn là cho rằng khách hàng luôn luôn đúng.

Vậy làm thế nào để bạn giữ bình tĩnh trong một tình huống như thế này? Hãy lịch sự nhắc nhở sếp rằng bạn càng đi làm sớm thì vấn đề này sẽ được khắc phục sớm.


1

Bằng cách xem sự kiện này là một cơ hội để cho thấy tôi có giá trị như thế nào (đối với doanh nghiệp) bằng cách đưa hệ thống sản xuất hoạt động trở lại nhanh nhất có thể (nếu không trước 9 giờ sáng ;-)).

Rõ ràng, hy vọng tôi đã không phá vỡ nó ngay từ đầu ;-)


1
  • sh_t xảy ra
  • phải có một giải pháp cho một vấn đề
  • Nếu ai đó trên thế giới biết giải pháp, tôi có thể là một trong số họ
  • nếu không có giải pháp, hoảng loạn không giúp được gì
  • một lần nữa, sh_t xảy ra

0

Vâng chắc chắn hỏi sếp của bạn rằng bạn sẽ quay lại với anh ta khi bạn giải quyết vấn đề; mặc dù trong những tình huống này, ban quản lý thường khiến những người khác tham gia để giải quyết nó càng sớm càng tốt, với người "có liên quan" sau đó ... Đó là tiêu chuẩn với bất kỳ công ty nào, bất kể ngành nào; Đối với kinh doanh, Khách hàng thường là Vua !!


0

Những tình huống như thế chỉ thúc đẩy tôi nhiều hơn để có một tài liệu kỹ lưỡng về mọi thứ, và một kế hoạch kỹ lưỡng để xử lý mọi tình huống.

Ngay cả khi chúng tôi không thể dự đoán mọi vấn đề có thể xảy ra, nhưng chúng tôi có thể giải quyết vấn đề của mình, để chuẩn bị kỹ lưỡng hơn, có tổ chức và ghi chép lại.


1
Tôi chưa bao giờ giải quyết vấn đề sản xuất (tức là hệ thống ngừng hoạt động) bằng cách sử dụng tài liệu.
Marcie

1
Không, nhưng nếu bạn cần tìm kiếm một cái gì đó, như thông số kỹ thuật, định nghĩa bảng, cài đặt máy chủ, bạn phải trả tiền để có tài liệu.
crosenblum

0

Tôi đã dành 8 năm để bảo trì máy bay ném bom B52G trong một cảnh báo 5 phút cho Thế chiến thứ ba. Điều đó đặt mọi thứ trong quan điểm cho tôi.

Một hệ thống sản xuất xuống rất quan trọng, nhưng nó sẽ không giết chết hàng triệu hoặc hàng tỷ người.

Tìm hiểu những gì sai, tìm nguyên nhân, khắc phục nó. Thiết lập thông tin liên lạc rõ ràng với những người quan trọng và giữ cho họ thông báo. Nói với sếp của bạn những gì bạn đang làm và khi nào bạn có thể cập nhật anh ta có thể ngăn chặn những tin nhắn và cuộc trò chuyện "đã được sửa chưa".

thực hiện thông qua khám nghiệm tử thi và tìm ra cách ngăn chặn và hạn chế ảnh hưởng của những sự cố như vậy trong tương lai.

Nếu bạn đang thực hiện cuộc gọi, việc có pin chết trên điện thoại di động hoặc tiếng bíp là cực kỳ không chuyên nghiệp. Điều này được tạo thành kịch bản chung, nhưng nếu điều này xảy ra với một người làm việc cho tôi, sẽ có một cuộc thảo luận nghiêm túc và nếu nó được lặp lại, họ sẽ không còn làm việc cho tôi nữa. Vâng, tôi là một người cứng rắn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.