Điều gì được khuyến nghị để ghi lại một ngăn xếp công nghệ CNTT, bao gồm mối quan hệ của chúng với nhau, trong cơ sở dữ liệu đồ thị?

Làm việc cho một công ty lớn với hơn 500 nhân viên CNTT và hơn 1.000 máy chủ, với mỗi máy chủ chạy các ứng dụng kinh doanh riêng, chúng tôi có một thách thức lớn về thông tin và phối hợp trong việc biết nhân viên CNTT nào sẽ liên lạc với máy chủ nào. Vấn đề phối hợp được kết hợp với các nhân viên CNTT khác nhau chịu trách nhiệm cho các lớp khác nhau của ngăn xếp CNTT. Ví dụ, có các nhóm khác nhau chịu trách nhiệm về phần cứng, ảo hóa, hệ điều hành, máy chủ ứng dụng và chính các ứng dụng.

Xem xét thách thức này, trong DevOps có một yêu cầu xác định và ghi lại tất cả các thành phần cấu thành các ngăn xếp công nghệ khác nhau trong môi trường CNTT. Theo truyền thống, điều này có thể đã được thực hiện bằng một giải pháp CMDB sở hữu.

Tôi đã điều tra các giải pháp CMDB điển hình như BMC Atrium và các giải pháp khác cho mục đích này, tuy nhiên vấn đề là chúng dừng ở cấp độ tài liệu CNTT, ở mức cao, theo khung ITIL, nhưng không giải quyết được tài liệu của Stack công nghệ CNTT một cách chi tiết. Tôi cũng đã điều tra các công cụ như Puppet , Ansible và Salt , nhưng các công cụ này tập trung nhiều hơn vào việc triển khai và cấu hình phần mềm, chứ không tập trung vào sự phối hợp của mọi người xung quanh phần mềm.

Ví dụ, một giải pháp khả thi sẽ xác định các khái niệm khác nhau, cùng với các thuộc tính quan trọng đối với các khái niệm này:

• Phần cứng
• Ảo hóa
• Các hệ điều hành
• Máy chủ ứng dụng
• Các ứng dụng

Những khái niệm này sau đó sẽ được liên kết với nhau về mối quan hệ của họ để tạo thành giải pháp. Ví dụ: một ứng dụng sẽ phụ thuộc vào một máy chủ ứng dụng, phụ thuộc vào hệ điều hành, v.v., cùng với giải pháp này sẽ được xác định tại "Hệ thống tài chính". Khi đã xác định một hệ thống, tất cả các siêu dữ liệu được liên kết với các hệ thống này sẽ được thu thập để tạo điều kiện phối hợp cho từng lớp trong ngăn xếp. Tức là sự phối hợp của các nhân viên hỗ trợ kỹ thuật cho mỗi lớp.

Mục đích của một giải pháp như vậy sẽ thực hiện các truy vấn khác nhau đối với các ngăn xếp công nghệ, chẳng hạn như:

• Để xác định ai hỗ trợ thành phần nào
• Những thành phần nào đã lỗi thời
• Những thành phần nào cần được vá

Với ý nghĩ này, những công cụ nguồn mở nào tồn tại để xác định tất cả các thành phần của ngăn xếp công nghệ CNTT, bao gồm cả mối quan hệ của chúng với nhau, trong cơ sở dữ liệu đồ thị như Neo4J?

Xem xét đoạn đầu tiên của bạn, tổ chức bạn mô tả là một tổ chức cực kỳ im lặng, đó chính xác là điều mà một tổ chức DevOps có xu hướng tránh.

Xem xét thách thức này, trong DevOps có một yêu cầu xác định và ghi lại tất cả các thành phần cấu thành các ngăn xếp công nghệ khác nhau trong môi trường CNTT. Theo truyền thống, điều này có thể đã được thực hiện bằng một giải pháp CMDB sở hữu.

Những gì bạn mô tả ở đây có thể là ITIL, đây là một hệ thống quản lý yêu cầu tài liệu và bạn kết hợp nó với thực tế, nhóm DevOps thường sẽ xác định các lớp bên dưới là mã, vì vậy, nó sẽ quay trở lại bất kỳ tài liệu phát triển nào có mã hóa là Tài liệu thường thấy trong phương pháp Scrum cho một phương pháp phát triển nhanh (lặp lại nhanh và ngắn nhằm vào giải pháp làm việc tối thiểu ở cuối vòng lặp)

Tuyên bố miễn trừ trách nhiệm cho phần còn lại của câu trả lời này: Tôi biết nhiều hơn về đầu bếp và người truyền cảm hứng và đó là lý do tại sao tôi coi họ là gương mẫu ở đây; nhưng chúng không phải là công cụ duy nhất hiện có trên thị trường, tôi sẽ không mở một cuộc tranh luận về chúng vì cái tốt hơn là thứ bạn thấy thoải mái hơn.

Vì vậy, phần còn lại của câu hỏi hơi thiên vị và cá nhân tôi đã không gặp phải một tổ chức ghi lại mối quan hệ lớp mà bạn mô tả nhiều hơn cơ sở hạ tầng như tài liệu mã hệ thống quản lý cấu hình và mã. (Một lần nữa, điều này không có nghĩa là không ai làm điều đó, tôi chỉ chưa bao giờ nghe về nó).
Để minh họa từ công ty của tôi trong môi trường đầu bếp, một cuốn sách nấu ăn ứng dụng sẽ khai báo các phụ thuộc của nó (tomcat, jboss, nginx / php và trên hệ điều hành nào, cần gắn điểm cho một số dữ liệu được chia sẻ và hầu hết tên lược đồ DB của nó) và hiển thị URI dịch vụ của nó được đầu bếp sử dụng cho cấu hình các ứng dụng khác, âm thanh này giống như xác định 'Hệ thống tài chính' của bạn và tài liệu về nó có trong cuốn sách nấu ăn ứng dụng README này, với một số tệp khác nếu thực sự cần thiết.

Các hệ thống quản lý cấu hình thường có một nơi báo cáo trung tâm, "đầu bếp-máy chủ" cho dữ liệu "quản lý giao diện người dùng" để trình bày trong thế giới đầu bếp "tháp ansible" để thế giới có thể đặt tên cho hai trong số chúng, nhưng chúng thường nhắm đến việc giám sát nhiều hơn hệ thống quản lý tổng thể hơn đồ thị phụ thuộc.

Điều đó nói rằng, đối với đầu bếp, máy chủ đầu bếp cũng hoạt động như một CMDB mà bạn có thể truy vấn bằng nhiều công cụ khác nhau (nó trả về dữ liệu JSON từ các yêu cầu HTTP), các phụ thuộc giữa các ứng dụng có thể được thể hiện theo nhiều cách khác nhau và không có 'ngoài luồng' Phương pháp, mỗi công ty sẽ có cách riêng để khai báo chúng trong hệ thống cho mục đích cấu hình và do đó bạn có thể tận dụng điều này để xây dựng biểu đồ của mình, nhưng đó là về phía bạn.

Trong một cơ sở hạ tầng theo quan điểm mã, các nhu cầu cơ sở hạ tầng sẽ được duy trì cùng với ứng dụng, nó vẫn là ứng dụng biết nó cần gì dưới dạng trung gian, hệ điều hành nào, với ngôn ngữ nào, phụ thuộc dịch vụ nào khác và dịch vụ nào ứng dụng này cung cấp).

Điều cuối cùng tôi có thể nghĩ đến nếu bạn muốn quản lý các phụ thuộc đó cho tài liệu chỉ là các công cụ như glpi , chủ yếu là CMDB và hệ thống bán vé, nó tận dụng tài liệu tài liệu và mối quan hệ của chúng để có thể biết những gì bị ảnh hưởng khi bạn mở một vé nói rằng một ứng dụng bị hỏng cùng với ng-Invent, nó cho phép truy vấn các trạng thái hệ thống và như vậy có thể đáp ứng truy vấn của bạn cho các nhu cầu vá, nhưng theo tôi đây là một nhiệm vụ của hệ thống kiểm toán, giống như có thể kiểm tra được tích hợp trong một đầu bếp, ví dụ như giai đoạn tiếp theo để sửa chữa các hệ thống lỗi thời bằng cách cập nhật / vá chúng.