Tai nạn SysAdmin tồi tệ nhất [đã đóng]

Phù hợp với câu hỏi về tai nạn sysadmin tốt nhất , tai nạn tồi tệ nhất bạn gặp phải là gì? Không giống như câu hỏi trước, tôi có nghĩa là "tồi tệ nhất" theo nghĩa là hầu hết các thiệt hại hệ thống hoặc thiệt hại thực tế cho mọi người.

Tôi sẽ bắt đầu với tôi:

Chúng tôi có hai tủ điện từ xa ở cuối hành lang 100 feet có một lưới kim loại cho sàn nhà. Sau khi chúng tôi lắp đặt cáp Cat6, các nhà thầu đã dọn sạch tất cả các mảnh vụn rơi qua lưới sắt vào bê tông 3 feet bên dưới. Một đồng nghiệp và tôi vào hành lang để kiểm tra tiến độ một ngày nhưng bị phân tâm và không nhận thấy rằng một mảnh lưới đã được chuyển sang một bên. Bạn thân của tôi bước lên không trung và ngực anh đập vào xà ngang thép. Anh ta bị gió và đau đủ để nghỉ một vài ngày, nhưng may mắn là chùm thép có các cạnh tròn và kích thước của lỗ mở sao cho anh ta không đập đầu vào nó hoặc sàn nhà bên dưới.

Rõ ràng chúng tôi đã học được rằng các khu vực mà sàn được loại bỏ một phần cần phải được gắn cờ.

Hãy tưởng tượng nếu bạn sẽ sống ở Nam Florida trong cơn bão Andrew (một chút trước cơn sốt 24X7). Tất cả các máy chủ của bạn được khóa an toàn trong một tòa nhà yêu cầu bạn huy hiệu vào đó và một khu vực an toàn hơn yêu cầu quét thêm huy hiệu của bạn. Hãy tưởng tượng một nitwit không tính đến việc cần tay cầm thực tế trên cửa. Hãy tưởng tượng một hợp đồng bốn triệu đô la đòi hỏi một giao hàng, điện gần nhất là 230 dặm về phía bắc, khí đốt đang khan hiếm, những con đường nguy hiểm, và một máy phát điện được thiết kế để cung cấp 48 giờ điện. Cười nếu bạn sẽ ở một bộ sưu tập các máy chủ ở phía sau của một chiếc xe tải, bị mắc kẹt trên chiếc chìa khóa của chuột Mickey, bị đình trệ vì muốn xăng. Cười nếu bạn sẽ hoàn toàn thiếu một cái cớ về việc tất cả đã đi từ quan điểm hậu cần, sysadmin và hoạt động như thế nào.

Khi tôi làm việc cho Cisco, tôi đã từng gặp những khách hàng đã mua thẻ không dây $ 30 và họ đã nhổ chip khi trình điều khiển của họ không cài đặt hoặc những người có bộ định tuyến cơ bản rẻ nhất mà Cisco có thể phát cuồng và giải quyết các vấn đề hỗ trợ.

Một ngày nọ, tất cả đã được đặt trong bối cảnh, khi tôi nhận được một cuộc gọi từ một trong những nhà cung cấp thẻ lớn nhất thế giới (nghĩ Amex, Mastercard, Visa, Diners ... thực tế đó là một trong những thương hiệu đó, tôi không biết liệu họ có biết không sẽ đánh giá cao tôi đề cập đến nó). Tôi là người hỗ trợ tuyến đầu, công việc duy nhất của tôi là đánh giá kịch bản, đánh giá và đưa nó đến bộ phận hỗ trợ phù hợp. Trường hợp này là trường hợp ưu tiên duy nhất tôi từng đưa ra.

Một người đàn ông từ công ty thẻ gọi và nói rằng mối liên kết giữa các máy tính lớn ở phía đông và tây bờ biển của họ đã bị sập. Nếu một tài khoản được tạo trên một máy tính lớn, giao dịch luôn được xử lý trên máy tính lớn đó. Sẽ ổn nếu liên kết gần nhất của bạn luôn ở gần máy tính lớn đó. Nhưng vào ngày đặc biệt này, nếu bạn có một tài khoản trên máy chủ bờ đông, nhưng bạn ở bờ tây, giao dịch sẽ bị từ chối vì liên kết không hoạt động.

Câu hỏi tiêu chuẩn khi đánh giá thiệt hại là "Chi phí này cho doanh nghiệp của bạn là bao nhiêu?" Câu trả lời, bình tĩnh và được thu thập, là "Khoảng một triệu đô la cứ sau 30 giây".

Thực sự đặt nó vào bối cảnh vào lần tới khi bạn cảm thấy muốn lôi cuốn và phát cuồng để hỗ trợ khách hàng qua thẻ không dây $ 30 của bạn.

(cần lưu ý rằng Cisco đã liên kết và chạy trong vòng 5 phút sau khi được chuyển)

Rất phổ biến đối với các lệnh bí danh như rm hoặc mv để thêm tùy chọn '-i' để tránh nhầm lẫn. Nhưng điều này xảy ra trong công ty của tôi một thời gian trước đây. Ai đó đặt dòng này trong .bashrc của root vào một trong các máy chủ.

alias rm='rm -i'

Sau đó, nó sao chép dòng và thay thế rm cho mv ... hoặc vì vậy, anh nghĩ:

alias rm='rm -i'
alias mv='rm -i'

Phần còn lại là lịch sử :)

Chà, vấn đề là khi bạn đặt câu hỏi 'bạn có chắc không' đã nói 'xóa' thay vì 'di chuyển' nhưng ...

Chúng tôi đã cài đặt một hệ thống Điểm bán hàng khổng lồ tại một nhà bán lẻ lớn (hơn 1000 chi nhánh). Máy chủ bỏ phiếu trung tâm là tất cả mã HP-Unix tùy chỉnh và thử nghiệm di chuyển sản xuất được xử lý bởi một anh chàng duy nhất - con trai của Giám đốc CNTT.

Anh chàng này đã dành 7,95 giờ mỗi ngày để đọc tiểu thuyết Fantasy, và vài phút khác điều hành công việc hàng loạt của mình để di chuyển các bản dựng hàng đêm sang sản xuất. Hệ thống này đã hoạt động được 3 ngày tại 150 chi nhánh (triển khai "thực sự" đầu tiên của chúng tôi). Mọi thứ đã được định sẵn và nhóm của tôi vừa hoàn thành việc kiểm tra các đoạn mã cuối cùng. Chúng tôi cam kết những thay đổi của chúng tôi và chuyển hình ảnh của chúng tôi từ phát triển sang thử nghiệm để được con trai của Giám đốc CNTT đón vào sáng hôm sau.

Tôi đến đó lúc 8:00 sáng và mọi thứ đang hỗn loạn. Hóa ra con trai đã được hướng dẫn rằng sau khi sao chép tệp vào sản xuất, anh ta phải vào thư mục ./changed và gõ "rm -rf *". Vâng, có người thực sự nói với anh ấy điều này! Tất nhiên, anh ta đã vô tình làm điều này trên ổ đĩa gốc sản xuất, cũng là nơi lưu trữ cơ sở dữ liệu bỏ phiếu giao dịch của chúng tôi (tình cờ ngoại tuyến để sao lưu vào thời điểm đó, chỉ là may mắn của chúng tôi).

Kết quả: 16 cửa hàng thí điểm của chúng tôi đã phải phục vụ khách hàng trong số các hộp xì gà (trong một số trường hợp, theo nghĩa đen) trong 2 ngày. Con trai của CIO bị hạ cấp xuống Server Watcher (anh ta ngồi trong phòng máy chủ lạnh cóng và được cho là để đèn đỏ ... nhưng anh ta không được phép chạm vào bất cứ thứ gì ... họ thậm chí không cho anh ta một máy tính và thu hồi tất cả thông tin đăng nhập / email của anh ấy). Nhóm phát triển của chúng tôi đã xây dựng lại toàn bộ dữ liệu bị mất từ ​​các bản sao lưu và kiểm tra lại / gửi lại mã.

Chúng tôi may mắn thực hiện triển khai 150 chi nhánh, nhưng đó là trải nghiệm triển khai tồi tệ nhất EVER.

Tôi đã học cách hoàn thành mọi câu lệnh trước khi nhấn phím Enter.

Một tình huống hơi giống tôi gặp phải là khi tôi không chắc chắn về một lệnh, tôi nhấn Home và gõ một số ký tự rác để lệnh không được nhận dạng.

me@mypc:~$ sdkjfhdsudo mv --too-many --switches-to-be --comfortable --working-with --while-running --an-important-command /here/this /there/that

bash: sdkjfhdsudo: command not found

Và sau đó tôi kiểm tra các tùy chọn một lần nữa, từ từ nếu cần. Có ai khác làm một điều như vậy. Tất nhiên, bạn phải đảm bảo rằng bạn nhập đủ số ký tự rác (5+) , để ngăn không cho nó trở thành một lệnh hợp lệ khác và gây ra thiệt hại khó lường hơn.

(Có một lỗ hổng cơ bản nào trong vấn đề này mà tôi chưa tìm ra hoặc một tình huống, với 5+ ký tự rác, điển hình là trong các phím "asdfghjkl", nó có thể đoán được điều gì không?

Khi cài đặt lại hệ điều hành của máy tính xách tay cho người quản lý, ai đó đã tạo một bản sao của tất cả dữ liệu của nó qua mạng tới một trạm linux trong / tmp. Có một số vấn đề và phải mất hơn một ngày.

... trạm linux đã ngừng hoạt động vào cuối ngày ...

Ngày hôm sau, khi họ đi tìm dữ liệu của người quản lý ...

Tôi đã làm việc với tư cách là một SysAdmin được khoảng 7 tháng, một trong những nhiệm vụ đầu tiên của tôi là chạy một máy chủ proxy Squid và tôi thực sự đã làm cho nó hoạt động, như 2 tuần sau đó tôi đã sử dụng BackTrack và làm hỏng rất nhiều công cụ " Chơi Hacker "Tôi thực sự đã hack máy chủ khá tốt nhưng sau khi tôi gặp phải một số lý do kỳ lạ, tôi đã thực hiện một rm -rf từ / và cũng xóa một phần của HĐH (Debian linux).

Tôi đã học cách hoàn thành mọi câu lệnh trước khi nhấn phím Enter.

Chúc mừng.

Một trong những khách hàng của chúng tôi đã gặp phải một lỗi hệ thống tập tin XFS khá phổ biến vào ngày 24 tháng 12 năm 2005 ... Lúc đó tôi không biết đó là lỗi kernel linux, tôi nghĩ đó chỉ là một số nghi ngờ thông thường (RAID 13TB với 8KB miễn phí, lỗi ổ đĩa giả trong mảng, v.v.).

Cuối cùng, vì hệ thống tập tin không thể đếm được, tôi đã yêu cầu người vận hành trên dòng nhập xfs_repair -n /dev/whatever. Hmm, nó muốn xóa nhật ký (rõ ràng, vì FS không thể gắn kết), nhưng không có thông báo quá đáng ngại. Vì vậy, đi cho nó : xfs_repair /dev/whatever.

15 phút sau, cô gọi lại:

Tại sao tôi không thể xem hầu hết các tệp?

Hu oh ... Hóa ra để thêm sự xúc phạm đến thương tích, các xfspross là một phiên bản nào đó sẽ gây tổn hại nghiêm trọng trong trường hợp chính xác này ... Ouch. 8TB dữ liệu đã biến mất.

Cơ sở colo của tôi đã có một số thời gian chết trở lại.

Họ đã gỡ bỏ liên kết mạng chính của họ với internet để thực hiện một số bảo trì phần mềm trên bộ định tuyến, đủ công bằng.

Tuy nhiên, cùng lúc đó, nhà cung cấp ngược dòng của liên kết phụ đã tắt nó để thực hiện một số thử nghiệm (rõ ràng họ đã được thông báo, nhưng nó đã bị ghi sai trong trung tâm dữ liệu)

Cho đến nay thật tệ ... tuy nhiên, khách hàng gặp khó khăn khi đến cơ sở để mang lại thời gian ngừng hoạt động cho nhà cung cấp .. nhà cung cấp chỉ có điện thoại VoIP, được kết nối thông qua ... tốt, bạn có thể đoán.

Tôi tưởng tượng bạn sẽ không tin tôi, nhưng đó là sự thật và là một vấn đề kỷ lục trên thế giới blog :)

Tôi không chắc rằng đây có thể là một câu trả lời thú vị, nhưng tôi cũng là một lập trình viên. Tôi đã mã hóa trang web cuối cùng của mình hoàn toàn trên một bản phát hành sản xuất, không có bản sao lưu nào trên máy tính của tôi. Một ngày tồi tệ sau 16 giờ làm việc liên tục, tôi phải tìm một phân vùng và cách nhanh nhất để làm điều đó là định dạng nó. Tôi fdisk -lchạy để kiểm tra tên của phân vùng tôi phải định dạng là gì, và không may là tôi đã đọc sai dòng và định dạng nó.

Tôi mất như 6 tháng làm việc.

May mắn thay, lần thứ hai bạn làm điều tương tự bạn làm nó tốt hơn và nhanh hơn, vì bạn đã biết cách làm điều đó. Bây giờ trang web đang hoạt động. Và tôi có bản sao lưu: =)