Có bất kỳ mô hình chống nổi tiếng nào trong lĩnh vực quản trị hệ thống không? [đóng cửa]

Tôi biết một vài mô hình phổ biến dường như sắp xảy ra gần như mọi dự án tại một số thời điểm trong vòng đời của nó:

1. Không có khả năng mất điện
2. Các thành phần bên thứ ba khóa nâng cấp
3. Môi trường không đồng đều
4. Thiếu theo dõi và cảnh báo
5. Thiếu dự phòng
6. Thiếu năng lực
7. Quản lý thay đổi kém
8. Chính sách truy cập quá tự do hoặc chặt chẽ
9. Thay đổi tổ chức làm mờ sở hữu cơ sở hạ tầng

Tôi đã hy vọng có một số thư viện được khớp nối tốt của các mô hình chống này được tóm tắt trong một cuốn sách hoặc trang web. Tôi gần như tích cực rằng nhiều tổ chức đang học thông qua thử nghiệm bằng phương pháp chữa cháy. Nếu không hãy bắt đầu một.

Để các tác vụ tự động hóa được tự động hóa cho đến khi thực hiện chúng một cách thủ công chiếm đủ thời gian mà chúng không thể được tự động hóa, bởi vì thực hiện các tác vụ thủ công ăn mọi lúc.

Ngược lại, tự động hóa sớm. Hoàn toàn không cần phải mất 3N giờ để tự động hóa tác vụ một lần mà phải mất N giờ để thực hiện thủ công (ngay cả khi việc tự động hóa thú vị hơn là tự mình lướt qua mọi thứ bằng tay).

A. không kiểm tra khôi phục - một bản sao lưu có thể được xác minh và ok, nhưng làm thế nào để khôi phục?

Mất bao lâu, mất bao lâu? Bạn phải biết làm điều đó trong một tình huống căng thẳng ...

B. không quản lý cấu hình, không đồng nhất - chỉ là một thay đổi ở đây và ở đó và tôi nghĩ rằng tôi đã điều chỉnh một số ở đây ...

Ai biết làm thế nào để sao chép một máy chủ được thực hiện tốt nếu tất cả các quirks không được viết ra và không có cấu hình giống hệt nhau trong cửa hàng? Điều gì nếu bạn thành công để khôi phục dữ liệu, nhưng không cấu hình, ứng dụng?

C. không giám sát - không biết làm thế nào và hộp nào đang làm

Đây là hai mặt: a) bạn phải theo dõi các báo động để phản ứng kịp thời trước khi bạn hết một số tài nguyên hoặc hành vi lạ và b) bạn phải theo dõi xu hướng dài hạn để quản lý dung lượng (đĩa, CPU, RAM, mạng ,. ..).

D. không có sự dư thừa trong cfg của bạn - điều gì xảy ra khi XX chết

Điều này có nghĩa là lập kế hoạch trước những gì bạn muốn về sysadmin của bạn.

Đối với tôi đây là những điều quan trọng nhất.

Mô hình giết người nhiều nhất là khi bộ phận quản trị hệ thống (hoặc toàn bộ CNTT) trở thành người tham gia thụ động trong công ty. Đó là, chúng được xem như là một dịch vụ tự phục vụ, nơi mọi người đều có những ý tưởng đã được hình thành về cách mọi thứ nên được thực hiện, điều này khiến người dùng chỉ cần xem xét và không phải là nhu cầu của toàn bộ hệ sinh thái CNTT.

Mô hình giết người thứ hai là khi bộ phận quản trị hệ thống biến thành một nhóm các nút ấn, tức là tất cả phần mềm / công cụ được mua hoặc phát triển và cài đặt bởi bên thứ ba và quản trị hệ thống được đào tạo chính thức và hướng dẫn sử dụng và sau đó chỉ làm theo hướng dẫn vận hành và leo thang đến nhà cung cấp mọi thứ không rõ ràng trong hướng dẫn. Tình huống này có thể rất thoải mái đối với (một số nếu không phải hầu hết) các quản trị viên hệ thống nhưng đây là một thảm họa đang chờ xảy ra khi thực tế là không ai thực sự biết toàn bộ hệ thống thực sự hoạt động như thế nào (nghĩ rằng sự tương tác tinh tế giữa các thành phần và trò chơi đổ lỗi giữa các nhà cung cấp).

1) quá hứa hẹn và cung cấp dưới mức (nghĩa là giữ cho kỳ vọng của người dùng thực tế)

2) Không xác minh sao lưu cho đến khi cần thiết.

chỉnh sửa: Tôi dự định số 2 để bao gồm khôi phục các tập tin / dữ liệu

Không theo dõi các mẫu sử dụng tài khoản AD như thời gian đăng nhập lần cuối> 30 ngày

(Chúng tôi phải làm điều này vì lý do kiểm toán, nhưng kết quả khá sốc)

• Giữ thông tin chính trong thư mục đầu / hộp thư đến / tài liệu của một người. Nếu nó quan trọng, như chi tiết liên hệ của nhà cung cấp, khóa cấp phép, hướng dẫn thiết lập, nó phải có sẵn cho tất cả mọi người trong bộ phận có thẩm quyền và có thể cần truy cập vào nó, và ở một nơi tiêu chuẩn.

• Hỏi người biết về một cái gì đó để ghi lại nó. Điều này nghe có vẻ tốt bởi vì họ là người có kiến ​​thức, nhưng thực sự nó rất tệ bởi vì họ không thể dễ dàng biết được kiến ​​thức quan trọng là gì. Tốt hơn là có ai đó thỏa thuận mới với nó, hỏi người hiểu biết bất kỳ thông tin nào họ cần và yêu cầu họ làm tài liệu khi họ làm điều đó.

• Tài liệu không rõ ràng. Bất cứ ai cũng có thể khắc phục sự cố ưu tiên trung bình trong ngày với toàn bộ bộ phận CNTT có sẵn để nói chuyện. Đây là một vấn đề khác để khắc phục sự cố ưu tiên cao vào đêm khuya khi bạn gần như một mình và không biết tại sao hệ thống được thiết lập như thế nào hoặc tại sao nó không khớp với những gì tài liệu nói.

• Không theo dõi mật khẩu tốt. Vì vậy, bạn nhanh chóng cần một tài khoản, tạo một tài khoản với mật khẩu ngẫu nhiên và sau đó 18 tháng nó vẫn được sử dụng và không ai biết mật khẩu hoặc dịch vụ nào sẽ bị hỏng nếu bị thay đổi.

• Không mua hỗ trợ của nhà cung cấp cho các hệ thống chính vì nó "quá đắt".

• Ưu tiên không phù hợp. Nhân viên CNTT cần được hướng dẫn bởi ban quản lý - một thỏa thuận trong đó các dự án là ưu tiên hoặc trong trường hợp khẩn cấp cần có hệ thống nào trước tiên. Nếu CNTT đang cố gắng khắc phục hệ thống kinh doanh, ban quản lý đang yêu cầu email và người dùng đang yêu cầu xử lý đơn hàng thì đó là một công thức cho một mớ hỗn độn.

• Các giải pháp không phù hợp - rất dễ để CNTT bị mắc kẹt trong suy nghĩ "để khắc phục nó, hệ thống CNTT phải hoạt động như trước đây", khi có thể có một thỏa thuận quản lý-CNTT phù hợp hơn để "thử 2 hàng giờ, nếu nó không được sửa thì hãy dừng lại ngay cả khi nó có vẻ đầy hứa hẹn và chuyển sang phục hồi từ bản sao lưu. "

• Bản sao của các tập tin thử nghiệm ở khắp mọi nơi. Bạn không muốn mở một thư mục chạy hệ thống kinh doanh hoặc trang web và xem "website-new /, website-current /, website-copy /, website-tests /, website-test-dave /, website-use- this-one /, website-from-feb /, v.v.) Dev, sản xuất và thử nghiệm nên tồn tại và nên được tách biệt với mọi bộ phận liên quan (IT, dev, quản lý dự án, v.v.) biết những gì nên ở đâu và đồng ý về cách thay đổi được phê duyệt. Cũng cho các tập tin cấu hình.

• Thay đổi phê duyệt - ngay cả khi bạn chỉ có một cuộc thảo luận bằng lời trước, đừng đi thay đổi cách thức hoạt động của những thứ quan trọng mà không ai biết. Tùy thuộc vào bạn để quyết định những gì "quan trọng" bao gồm cho tình huống của bạn.

• Giải pháp cơ thể còn lại tại chỗ lâu dài. Tôi biết bạn đã vá máy chủ này qua mạng đó bằng dây điện thoại cũ nhanh chóng để bạn có thể giải quyết vấn đề khẩn cấp. Tôi biết bạn không có thời gian để làm lại nó đúng cách. Làm cho thời gian.

• Quan hệ kém với phần còn lại của công ty. CNTT là một dịch vụ giúp phần còn lại của công ty thực hiện công việc của họ. Nếu họ cần các tập tin lớn nhanh chóng, làm cho nó xảy ra. Nếu bạn cần sự chấp thuận của người quản lý để mua phần cứng, hãy lấy nó. Nếu bạn không thể có được nó, hãy thông báo rõ ràng rằng các tệp khổng lồ không thể di chuyển nhanh vì ban quản lý đã ưu tiên một số chi tiêu khác. Nếu bạn cần lưu trữ vì lý do pháp lý nhưng không có ngân sách thì bạn cần phải phù hợp với việc lưu trữ vào hệ thống của bạn tốt nhất có thể.