Quy tắc xử lý sự cố của bạn, cách tiếp cận để khắc phục sự cố? [đóng cửa]


22

Bạn có bất kỳ quy tắc chung nào mà bạn gặp phải khi khắc phục sự cố mạng / phần cứng / phần mềm khó khăn không?

Ví dụ: "Tôi cách ly nguồn của sự cố bằng cách kiểm tra thiết bị ngoại vi với máy tính thứ hai" hoặc "Tôi loại bỏ càng nhiều phần cứng càng tốt để cấp nguồn cho thiết bị, sau đó thêm lại từng bộ phận cho đến khi tôi có thể tái tạo vấn đề" v.v.


có lẽ tôi nên chỉnh sửa tiêu đề. tôi chỉ biết ai đó sẽ trả lời "cảm ơn! tôi tự hào về điều đó" ;-)
tên người dùng

Câu trả lời:


16

Chỉ là một danh sách các điểm tôi đã viết ra cho chính mình sau khi chiến đấu với một vấn đề trong một thời gian:

  1. Mục tiêu chính của bạn gì? Nên được nêu rõ ràng và chính xác. Mục tiêu nên rất đặc biệt. Nó không nên chung chung. Tốt nhấtmột câu .
  2. Vấn đề của bạn là gì ?
  3. Chỉ có một vấn đề hay nhiều ? Nếu có nhiều, giải quyết chúng cùng một lúc.
  4. Cố gắng tái tạo vấn đề với các điều kiện khác nhau . Nó có thể được sao chép trong tất cả các điều kiện có thể hay không? Nó có nói gì về bản chất của vấn đề không?
  5. Nếu nó là một vấn đề khẩn cấp thì có một cách giải quyết ? Cố gắng tìm càng nhiều cách giải quyết càng tốt.
  6. Cố gắng đưa ra càng nhiều dự đoán càng tốt về nguyên nhân của vấn đề của bạn.
  7. Cố gắng chứng minh dự đoán của bạn, thử nghiệm với hệ thống.
  8. Hãy đồng ý trong những gì bạn đang cố gắng làm. Làm một việc tại một thời điểm.
  9. Theo dõi những gì bạn đang làm, những gì bạn đã cố gắng.
  10. Đừng đi chệch khỏi mục tiêu chính của bạn. Liên tục kiểm tra xem bạn có còn giải quyết được vấn đề chính của mình không, không phải là vấn đề khác.
  11. Đừng không fixate một trong hai.

Ngoài ra còn có một danh sách tuyệt vời các quy tắc gỡ lỗi, nó ở dạng PDF với các ngoại lệ và giải thích cho từng quy tắc. Tôi không thể nhanh chóng tìm thấy bản PDF, nhưng tôi nghĩ đây là một poster của danh sách:

nhập mô tả hình ảnh ở đây


15
  • Nếu vấn đề liên quan đến Internet, có lẽ đó là DNS.

  • Nếu vấn đề khó chẩn đoán, có lẽ đó là RAM.

  • Nếu sự cố xảy ra với máy trạm Windows, có lẽ nhanh nhất để đánh giá lại nó.

  • Nếu vấn đề là vào thứ Sáu, có lẽ đó là một vấn đề nghiêm trọng.


Tôi muốn tải xuống một bài viết đùa, nhưng nó chính xác đáng ngạc nhiên!
TessellatingHeckler

Tôi thích # 3; không thể đúng hơn
Federer

10

Tôi thích quay lại phương pháp khoa học .

Từ ( http://en.wikipedia.org/wiki/Sellectific_method )

  1. Xác định câu hỏi
  2. Thu thập thông tin và tài nguyên (quan sát)
  3. Giả thuyết hình thức
  4. Thực hiện thí nghiệm và thu thập dữ liệu
  5. Phân tích dữ liệu
  6. Giải thích dữ liệu và rút ra kết luận đóng vai trò là điểm khởi đầu cho giả thuyết mới
  7. Kết quả tài liệu

Theo nguyên tắc chung, tôi luôn muốn thử và kiểm tra lại các giả định cơ bản của mình. Liệu nó có sức mạnh, nó được cắm vào, là hệ thống dây điện tốt. Sẽ rất khó chịu khi dành hàng giờ để cố gắng xem xét vấn đề phần mềm khi bạn có dây cáp lỏng lẻo.

Tôi thấy nó rất quan trọng trong giai đoạn tạo ra giả thuyết để thực sự đưa ra càng nhiều nguyên nhân có thể của vấn đề càng tốt. Sau đó, tôi thử và chọn ý tưởng để kiểm tra trước dựa trên mức độ dễ kiểm tra và khả năng của ý tưởng đó.

Nó cũng quan trọng để có được sự giúp đỡ. Tham khảo ý kiến ​​đồng nghiệp, nhà cung cấp hoặc bất cứ ai là người hiểu biết nhất về các hệ thống được đề cập nếu bạn có thể. Đừng dành nhiều thời gian để xoay bánh xe của bạn về một vấn đề nếu có ai đó có thể giúp bạn giải quyết vấn đề.

O'Reilly có một cuốn sách hay Các công cụ khắc phục sự cố mạng có một bộ các bước tốt để thực hiện rất giống với phương pháp khoa học. Tôi thấy cuốn sách rất hữu ích và rất khuyến khích nó. Cuốn sách đi sâu vào chi tiết hơn rất nhiều và gợi ý nhiều công cụ hữu ích.

Từ các công cụ khắc phục sự cố mạng

  1. Nêu mục tiêu của bạn
  2. Xác định hệ thống
  3. Xác định các kết quả có thể
  4. Xác định và chọn những gì bạn sẽ đo
  5. Nếu thích hợp xác định các thông số và yếu tố kiểm tra
  6. Chọn công cụ
  7. Thiết lập các ràng buộc đo lường
  8. Xem lại thiết kế thí nghiệm
  9. Thu thập dữ liệu
  10. Phân tích dữ liệu

Xem thêm:


Chắc chắn rồi. Mặc dù, bước 7 có phần hài hước. Tài liệu của tôi thường kết thúc như "Yep, nó đã được sửa. Bây giờ nó hoạt động."
squillman

Tôi tôn trọng phương pháp khoa học, nghĩ rằng tôi tin rằng trước khi nó xuất hiện nên có một yếu tố con người cần phải được thông qua. Ví dụ: tôi phải xem xét nguồn báo cáo (người báo cáo vấn đề) ... và hãy cẩn thận đừng cho rằng anh ấy / cô ấy là một nguồn 'đáng tin cậy' (bởi đáng tin cậy, ý tôi là anh ấy / cô ấy sẽ tốt tài nguyên để hỗ trợ tôi xác định câu hỏi, thu thập thông tin và hình thành giả thuyết đầu tiên của tôi).
l0c0b0x

10

(Những điểm nổi bật này được diễn giải từ chương "Gỡ lỗi" của "Thực hành quản trị hệ thống và mạng" )

Hai điều cần biết:

  1. Biết phiên bản "cố định" trông như thế nào. Tốt nhất là một lệnh bạn có thể chạy cung cấp một đầu ra nhất định khi mọi thứ hoạt động. Ví dụ: Tôi đang cố gắng tìm hiểu tại sao SSH yêu cầu mật khẩu khi tôi thiết lập các khóa chính xác (hoặc tôi nghĩ vậy). Vì vậy, thử nghiệm của tôi là: "ssh servername uptime" và nó sẽ hoạt động mà không cần hỏi mật khẩu.

  2. Mô tả vấn đề ở cấp độ phù hợp. Một người dùng phàn nàn rằng họ không thể ping máy chủ không nên gửi cho bạn để chạy và sửa chữa máy chủ. Công việc của người đó không phải là ngồi một chỗ và ping máy cả ngày. Họ muốn thực hiện một số loại nhiệm vụ như sử dụng máy làm máy chủ DNS của họ. Ví dụ: Một khi người dùng phàn nàn rằng họ không thể ping máy nửa vòng trái đất. Tôi dành cả ngày để theo dõi các sysadmin trong phần đó của công ty để tìm hiểu những gì đã xảy ra với máy đó. Nó đã ngừng hoạt động và họ đã hoảng loạn vì họ nghĩ có lẽ họ đã tắt máy. Tôi đã liên lạc với người dùng và nói "ngoài việc cần ping máy này, bạn muốn làm gì với nó?". Hóa ra anh ta muốn điều hành một công việc nhất định trên đó và nếu anh ta đã làm theo đúng quy trình, nhiệm vụ của anh ta sẽ được tự động chuyển hướng đến máy thay thế. Tôi đã lãng phí cả ngày và thời gian của các hệ thống địa phương. Một lý do khác "Tôi không thể ping" không phải là điều đúng đắn để kiểm tra: Thông thường tường lửa được cấu hình để bỏ các gói ping nhưng cho phép các gói khác đi qua. Kiểm tra những gì bạn muốn đi qua.

Hai chiến lược:

  1. Phụ gia: Tiếp tục thêm các thành phần cho đến khi vấn đề bắt đầu. Điều cuối cùng bạn thêm vào là vấn đề. Ví dụ: Trình duyệt web không thể nói chuyện với máy chủ. Giữa máy chủ và người dùng là bộ cân bằng tải, tường lửa, bộ đệm và proxy web cục bộ của người dùng. Trước tiên hãy thử gửi truy vấn trực tiếp đến máy chủ, sau đó qua LB đến máy chủ, sau đó qua tường lửa đến LB đến máy chủ, v.v. mỗi lần thêm một thành phần.

  2. Subtractive: Tiếp tục loại bỏ các thành phần cho đến khi vấn đề biến mất. Điều cuối cùng bạn xóa là vấn đề: Ví dụ: Một máy có hàng tá thẻ sẽ không khởi động. Tiếp tục tháo thẻ cho đến khi máy khởi động.

Hai bit may mắn câm:

  1. Quên tất cả những gì tôi nói. Vấn đề đang được gây ra bởi sự thay đổi cuối cùng được thực hiện cho hệ thống. (điều này hoạt động 99% thời gian ... vấn đề là 99% thời gian bạn không biết thay đổi cuối cùng thực sự là gì)

  2. Khi tất cả những thứ khác thất bại, hãy kiểm tra những thứ ngu ngốc. http://whatexit.org/tal/mywritings/dumb-things-to-check.html Ví dụ: Một vấn đề điên rồ không thể giải thích được. Sau đó, chúng tôi đã kiểm tra tệp cấu hình: một người dùng đã chỉnh sửa nó bằng cách sao chép nó vào hộp Windows, chỉnh sửa nó, sau đó sao chép lại. Bây giờ nó có một ^ M ở cuối mỗi dòng. Chúng tôi không bao giờ nhận thấy bởi vì trình soạn thảo văn bản của chúng tôi âm thầm che giấu sự thật này. Đáng buồn thay, phần mềm đọc tệp cấu hình đã biến những thứ đó ^ Ms thành một không gian không phá vỡ, làm hỏng hàng tấn các thủ tục khác.


6

Thực hành chung tôi nhớ trong toàn bộ quá trình:

  1. Viết tất cả mọi thứ tôi làm xuống.
  2. Chỉ thực hiện một thay đổi tại một thời điểm.
  3. Nếu có thể, hãy đảo ngược sự thay đổi trước khi thử cái khác trừ khi tiến trình xác định đang được thực hiện.

Trong quá trình khắc phục sự cố ở đây xác định phương pháp cơ bản của tôi:

  • Khi hệ thống hoạt động tốt và hoạt động tốt, trước khi có sự cố, tôi cố gắng học cách xem nó đang làm gì. Joe Richards giải thích tại sao tốt hơn nhiều so với tôi có thể trong không gian ngắn này .
  • Tôi bắt đầu với giải pháp đơn giản nhất. Chẳng hạn, không có kết nối mạng? Kiểm tra lớp vật lý. Tôi không thể nói cho bạn biết bao nhiêu lần sự cố kết nối không liên tục không phải là sự cố máy chủ mà là cáp mạng bị hỏng một nửa hoặc bị hỏng.
  • Tôi cố gắng nắm bắt tất cả các triệu chứng tôi có thể thấy từ tất cả các nguồn có khả năng trước khi tôi bắt đầu thay đổi.
  • Tôi chạy thử nghiệm chẩn đoán sơ bộ. Ví dụ, khi tôi được thông báo rằng một máy chủ không hoạt động, điều đầu tiên tôi làm là sử dụng ping và nbtstat (Windows) để xác minh điều đó. Vấn đề có thể nằm ở đầu xa (để mượn một câu nói kiểm soát công nghệ cũ của Không quân).
  • Tôi không ngại làm nghiên cứu. Google, support.microsoft.com, eventid.net và các trang web như thế là bạn của bạn.
  • Tôi không ngại yêu cầu sự giúp đỡ từ cộng đồng. Không chỉ các trang web như serverfault.com, nhưng tôi có rất nhiều người tôi tin tưởng và tôn trọng trên Twitter mà tôi vẫn giữ liên lạc.
  • Tôi đánh giá các câu trả lời tôi đang tìm kiếm với những gì tôi đang thấy. Tôi không cho rằng bất kỳ một giải pháp nào là đúng cho đến khi tôi có thể xem xét đủ các bằng chứng tôi thấy với những gì được báo cáo trong giải pháp.

6

Thái độ tôi cố gắng và giữ:

  • Sự tự tin tuyệt đối rằng nguyên nhân và kết quả hoạt động và không có gì là ma thuật. Không có gì xảy ra mà thực sự kỳ lạ, chỉ có những điều tôi không hiểu.
  • Hoàn toàn tin tưởng rằng nếu tôi tiếp tục thúc đẩy nó, tôi sẽ giải quyết nó (điều này có thể liên quan đến việc đưa nó đến một người hiểu biết hơn, học hỏi, yêu cầu giúp đỡ, làm việc chăm chỉ, v.v.).
  • Càu nhàu về cách thiết lập, chương trình hoặc kịch bản được thiết kế tồi hoặc thực sự ngu ngốc không giúp ích gì, vì vậy đừng làm điều đó. (Tôi thấy điều này khó khăn, càu nhàu là niềm vui).

Đây là những thái độ hữu ích cho tôi khi giữ - chúng ngăn tôi giơ tay lên không trung, tuyên bố điều gì đó "kỳ quái" và sau đó từ bỏ, hoặc không vui vì cảm thấy "không thể giải quyết".

Những cách tôi nghĩ về xử lý sự cố:

  • Các hệ thống có rất nhiều bộ phận, nếu chúng được kết nối với nhau hoặc được cấu hình ngẫu nhiên thì chúng sẽ không hoạt động như mong muốn. Có một hoặc hai cấu hình rất cụ thể sẽ hoạt động - trong tất cả hàng triệu cách để đóng gạch và kim loại, chỉ một số ít là cầu và chỉ một hoặc hai là cầu đủ tốt. Nguyên nhân có thể là một ký tự trong tệp văn bản hoặc máy chủ bị lỗi, nhưng mọi phần phải đúng cho toàn bộ điều đúng. Tôi cần phải sẵn sàng kỹ lưỡng và tỉ mỉ nếu cần. Các hệ thống không thể làm "chương trình phải tiếp tục".
  • Bạn bắt đầu với toàn bộ hệ thống như bản đồ, bạn tưởng tượng một đám mây xác suất nổi trên bản đồ thể hiện "vấn đề là ở đâu" và công việc của bạn là sử dụng kinh nghiệm và tìm các bài kiểm tra để đẩy xác suất ra khỏi một số khu vực và về phía những người khác và để ngưng tụ nó xuống các điểm có vị trí có vấn đề xác suất cao, sau đó tấn công chúng. Điều này trở lại điểm nguyên nhân và kết quả - vấn đề nằm ở hệ thống, nó không phải là phép thuật. Đó là một vấn đề tồn tại vì vậy nó phải tồn tại ở đâu đó.
  • Bất cứ điều gì có thể được thiết lập bất cứ cách nào bất cứ ai muốn. Cách duy nhất chúng ta có thể định nghĩa một hành vi là "OK" và hành vi khác là "vấn đề" là bởi vì những gì ai đó nhận được không phải là điều họ muốn. Bạn phải hiểu những gì họ muốn, những gì họ đang nhận được rõ ràng và cụ thể.

Quy trình xử lý sự cố:

  • Vấn đề là gì Hãy chắc chắn rằng bạn thấy nó đang xảy ra và có thể tự tái tạo nó để không có thông tin sai lệch. Vì vậy, thường có nhiều vấn đề xảy ra với một số người trong bộ phận trợ giúp của chúng tôi khi họ đến với tôi vẫn không ai có thể giải thích cho tôi vấn đề thực sự là gì.
  • Đó là phép chia đệ quy một lần nữa - phân chia và chinh phục, tìm kiếm nhị phân - bạn đưa ra một bài kiểm tra sẽ chứng minh nếu vấn đề nằm ở phía bên này của thử nghiệm, hay bên đó, và thực hiện thử nghiệm để loại bỏ càng nhiều càng tốt. Lặp lại cho đến khi giải quyết.
  • Đừng tìm hiểu nếu bạn có thể tránh nó - tốt hơn là khóa tài khoản cơ sở dữ liệu và chứng minh rằng sự cố vẫn xảy ra khi cơ sở dữ liệu không liên quan hơn là dành hàng giờ để tìm hiểu cách sử dụng cơ sở dữ liệu.
  • Thật quá dễ dàng để thấy mình nghĩ rằng "Tôi không biết phải làm gì tiếp theo". Lưu ý khi điều đó xảy ra và quay trở lại để đưa ra các bài kiểm tra xác định vấn đề.

Internet không hoạt động? Kiểm tra vấn đề, tìm một trang web mà họ không thể truy cập. Kiểm tra nhanh liên quan đến kết nối internet của họ (làm việc), nó có tải cho tôi không (không). Kiểm tra nhanh chỉ ra nó là trang web. Khi thấy vấn đề xảy ra với tôi, tôi đã nhanh chóng đẩy xác suất ra khỏi PC, trình duyệt, DNS, tường lửa văn phòng tài khoản người dùng, v.v.

Vì vậy, các trang web không tải, bây giờ những gì? Điều đó chưa thể khắc phục được, vì vậy hãy tìm những nơi khắc phục vấn đề thành một vấn đề nhỏ hơn. Là máy chủ trên? Nó có ping không? DNS có hoạt động không? Vâng. Dịch vụ có trả lời trên cổng 80 không? Không. Dịch vụ có chạy không? Không. Nó có bắt đầu không? Không. Nó có lỗi trong logfiles / logfiles không? Vâng! Họ nói cái gì?

Đây là cách khắc phục sự cố hiệu quả và nhanh chóng vì nó không ngừng tập trung vào việc thu hẹp phạm vi của vấn đề. Nếu tôi chấp nhận báo cáo của họ rằng internet không hoạt động, tôi sẽ lầm tưởng đó là lỗi kết nối. Nếu tôi chấp nhận lần đầu tiên nhìn thấy rằng nó không tải cho họ, tôi sẽ lãng phí thời gian trên máy tính của họ vì nghĩ rằng đó là lỗi.

Thực hiện các phần của "những thứ không thể" lớn nhất có thể.

Hiểu hệ thống. Tôi càng có nhiều kiến ​​thức tổng quát về một hệ thống, nó càng dễ dàng hơn. Khi tôi có sự hiểu biết yếu, các vấn đề đáng sợ hơn, khó khăn hơn, đi chậm hơn và có khả năng kết thúc với một cách giải quyết hơn là sửa chữa, hoặc với một sửa chữa chậm câm lớn (cài đặt lại) so với một sửa chữa phẫu thuật nhỏ, chính xác.


4

Nói chung tôi hỏi "Điều gì đã thay đổi có thể gây ra vấn đề này"? Hầu hết các vấn đề được gây ra bởi những thay đổi đối với cấu hình tốt đã biết. Nếu bạn có thể cô lập ai đã thay đổi thì bạn thường nhận được câu trả lời.


2

Tôi nghĩ đó là một kỹ năng, không phải là khoa học. Có những lúc bạn đi sai đường nhưng phần lớn:

  • Có hiểu biết cơ bản tốt về tất cả các công nghệ liên quan - Mạng, phần cứng, HĐH, phần mềm, phát triển, v.v. - sẽ giúp bạn loại bỏ một số "đường dẫn sai" đó
  • suy nghĩ cơ bản - đừng nhảy vào bối cảnh phức tạp nhất bởi vì nó nằm trong đầu bạn, thực hiện xử lý sự cố cơ bản của bạn và để nó dẫn dắt bạn.

Tôi đã từng có sếp gọi cho tôi với một kỹ sư "cao cấp" qua điện thoại - anh ta nói với tôi rằng anh ta có một máy chủ không thể kết nối và anh ta đã thử chuyển đổi cáp nhưng vẫn không có niềm vui. Tôi có thể nghe thấy tiếng bíp dưới nền như một UPS trên pin. Tôi hỏi anh ta nếu anh ta có thể thấy hoạt động trên công tắc, anh ta nói không. Tôi hỏi anh ta nếu tiếng bíp phát ra từ UPS, anh ta nói có, tôi hỏi anh ta nếu anh ta có thể nhìn thấy bất kỳ đèn nào trên giá anh ta nói không ... Nhìn ra ngoài mũi của bạn - nó giúp!


1

Tôi bắt đầu bằng cách kiểm tra rõ ràng. Có một thông báo lỗi giải thích vấn đề là gì? Là tất cả mọi thứ kết nối đúng? Tôi không muốn lãng phí vài giờ để khắc phục sự cố một cái gì đó có thể được giải quyết trong vài phút. Tôi nghĩ rằng nó có thể là quá phương pháp. Tôi đã thấy mọi người lãng phí cả ngày để tái tạo một vấn đề mặc dù thực tế tôi đã nói với họ chính xác vấn đề là gì. Đó không phải là những gì tôi trả cho họ.

Nếu câu trả lời không rõ ràng, hãy xếp hàng một số nghi phạm và kiểm tra chúng trước. Chỉ sau khi bạn kiểm tra các nghi phạm có khả năng, bạn mới nên kiểm tra các nghi phạm không có khả năng. Sau đó, bạn có thể được khoa học như bạn muốn.


hmm tôi đồng ý một phần - hoặc ít nhất tôi nghĩ rằng thật dễ dàng để tuân theo quy tắc của người khác mà không thực sự hiểu làm thế nào / khi nào thì phù hợp. Giống như học sinh trung học bị buộc phải học toán, nhưng sẽ không nhận ra tình huống mà họ có thể sử dụng những gì họ đã học được trong cuộc sống thực. Nhưng hiểu đúng thời điểm để áp dụng đúng quy tắc có thể thực sự là một lợi ích. Ví dụ: Google "Phương pháp HalfSplit" để biết ví dụ về quy tắc khắc phục sự cố hiệu quả cực kỳ hiệu quả
tên người dùng

Phương pháp loại trừ sự rõ ràng của bạn không phải là không khoa học. Bạn chỉ đang chạy qua một số bước lặp lại của các bước giả thuyết và thử nghiệm một cách nhanh chóng. Tôi hoàn toàn đồng ý bạn nên ưu tiên cho những ý tưởng mà bạn có thể kiểm tra nhanh chóng.
Zoredache
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.