Prohoster > Blog > quản lý > Từ outsourcing đến phát triển (Phần 1)

Từ outsourcing đến phát triển (Phần 1)

Xin chào mọi người, tên tôi là Sergey Emelyanchik. Tôi là người đứng đầu công ty Kiểm toán-Viễn thông, nhà phát triển chính và là tác giả của hệ thống Veliam. Tôi quyết định viết một bài về cách tôi và bạn tôi thành lập một công ty gia công, viết phần mềm cho chính mình và sau đó bắt đầu phân phối nó cho mọi người thông qua hệ thống SaaS. Về việc tôi thực sự không tin rằng điều này là có thể. Bài viết không chỉ có một câu chuyện mà còn có các chi tiết kỹ thuật về cách tạo ra sản phẩm Veliam. Bao gồm một số đoạn mã nguồn. Tôi sẽ cho bạn biết chúng tôi đã mắc phải những lỗi gì và chúng tôi đã sửa chúng như thế nào sau này. Có những nghi ngờ về việc có nên xuất bản một bài báo như vậy hay không. Nhưng tôi nghĩ thà làm điều đó, nhận phản hồi và cải thiện còn hơn là không xuất bản bài báo và nghĩ xem điều gì sẽ xảy ra nếu...

thời tiền sử

Tôi đã làm việc ở một công ty với tư cách là nhân viên CNTT. Công ty khá lớn với cấu trúc mạng lưới rộng khắp. Tôi sẽ không tập trung vào trách nhiệm công việc của mình, tôi sẽ chỉ nói rằng chúng chắc chắn không bao gồm sự phát triển của bất cứ điều gì.

Chúng tôi đã theo dõi, nhưng hoàn toàn vì sở thích học thuật, tôi muốn thử viết một bài đơn giản nhất của riêng mình. Ý tưởng là thế này: Tôi muốn nó xuất hiện trên web để tôi có thể dễ dàng truy cập mà không cần cài đặt bất kỳ ứng dụng khách nào và xem điều gì đang xảy ra với mạng từ bất kỳ thiết bị nào, kể cả thiết bị di động qua Wi-Fi và tôi cũng thực sự muốn nhanh chóng hiểu được tại sao có những thiết bị trong phòng đã trở nên “bẩn thỉu” bởi vì... có những yêu cầu rất nghiêm ngặt về thời gian đáp ứng những vấn đề như vậy. Kết quả là, trong đầu tôi nảy ra một kế hoạch là viết một trang web đơn giản có nền jpeg với sơ đồ mạng, tự cắt các thiết bị có địa chỉ IP của chúng trong ảnh này và hiển thị nội dung động ở trên cùng của hình ảnh ở tọa độ yêu cầu dưới dạng địa chỉ IP màu đỏ hoặc xanh lục nhấp nháy. Nhiệm vụ đã được đặt ra, hãy bắt đầu thôi.

Trước đây, tôi đã lập trình bằng Delphi, PHP, JS và C++ rất sơ sài. Tôi biết khá rõ mạng lưới hoạt động như thế nào. Vlan, Định tuyến (OSPF, EIGRP, BGP), NAT. Điều này là đủ để tôi tự viết một nguyên mẫu giám sát nguyên thủy.

Tôi đã viết những gì tôi dự định bằng PHP. Máy chủ Apache và PHP có trên Windows vì... Linux đối với tôi lúc đó là một thứ gì đó khó hiểu và rất phức tạp, hóa ra sau này tôi đã rất nhầm lẫn và ở nhiều chỗ, Linux đơn giản hơn nhiều so với Windows, nhưng đây là một chủ đề riêng và tất cả chúng ta đều biết có bao nhiêu holivar trên đó. chủ đề này. Trình lập lịch tác vụ của Windows kéo theo một khoảng thời gian nhỏ (tôi không nhớ chính xác, nhưng đại loại như cứ ba giây một lần) một tập lệnh PHP thăm dò tất cả các đối tượng bằng một lệnh ping tầm thường và lưu trạng thái vào một tệp.

system(“ping -n 3 -w 100 {$ip_address}“);

Vâng, vâng, tôi cũng chưa thành thạo việc làm việc với cơ sở dữ liệu vào thời điểm đó. Tôi không biết rằng có thể song song hóa các quy trình và việc xem qua tất cả các nút mạng mất nhiều thời gian, bởi vì... điều này đã xảy ra trong một chủ đề. Vấn đề đặc biệt nảy sinh khi một số nút không khả dụng, bởi vì mỗi người trong số họ trì hoãn tập lệnh trong 300 mili giây. Về phía máy khách, có một chức năng lặp đơn giản, trong khoảng thời gian vài giây, tải xuống thông tin cập nhật từ máy chủ với yêu cầu Ajax và cập nhật giao diện. Chà, sau 3 lần ping không thành công liên tiếp, nếu một trang web có tính năng giám sát được mở trên máy tính, một bản nhạc vui vẻ sẽ được phát.

Khi mọi thứ diễn ra suôn sẻ, tôi rất có cảm hứng với kết quả và nghĩ rằng mình có thể bổ sung thêm nhiều thứ hơn nữa (do kiến ​​thức và khả năng của mình). Nhưng tôi luôn không thích những hệ thống có hàng triệu biểu đồ, điều mà lúc đó tôi và cho đến ngày nay vẫn nghĩ là không cần thiết trong hầu hết các trường hợp. Tôi chỉ muốn đưa vào đó những gì thực sự giúp ích cho tôi trong công việc. Nguyên tắc này vẫn là nền tảng cho sự phát triển của Veliam cho đến ngày nay. Hơn nữa, tôi nhận ra rằng sẽ rất tuyệt nếu tôi không phải tiếp tục theo dõi và biết về các vấn đề, và khi nó xảy ra, sau đó mở trang và xem nút mạng có vấn đề này nằm ở đâu và phải làm gì với nó tiếp theo . Không hiểu sao hồi đó tôi không đọc email, đơn giản là tôi không sử dụng nó. Tôi tìm thấy trên Internet rằng có các cổng SMS mà bạn có thể gửi yêu cầu GET hoặc POST và họ sẽ gửi SMS đến điện thoại di động của tôi kèm theo văn bản tôi viết. Tôi ngay lập tức nhận ra rằng tôi thực sự muốn điều này. Và tôi bắt đầu nghiên cứu tài liệu. Sau một thời gian, tôi đã thành công và bây giờ tôi nhận được một tin nhắn SMS về sự cố mạng trên điện thoại di động của mình với tên “vật thể rơi”. Mặc dù hệ thống này còn thô sơ nhưng do chính tôi viết ra và điều quan trọng nhất thúc đẩy tôi phát triển nó là vì nó là một chương trình ứng dụng thực sự giúp ích cho tôi trong công việc.

Và rồi đến ngày một trong các kênh Internet bị hỏng tại nơi làm việc và việc giám sát của tôi không cho tôi biết về điều đó. Vì DNS của Google vẫn ping hoàn hảo. Đã đến lúc suy nghĩ về cách bạn có thể theo dõi xem kênh liên lạc có còn hoạt động hay không. Có nhiều ý tưởng khác nhau về cách thực hiện việc này. Tôi không có quyền truy cập vào tất cả các thiết bị. Chúng tôi phải tìm cách hiểu kênh nào đang hoạt động nhưng không thể xem kênh đó trên chính thiết bị mạng bằng cách nào đó. Sau đó, một đồng nghiệp đã nảy ra ý tưởng rằng có thể việc dò đường đến các máy chủ công cộng có thể khác nhau tùy thuộc vào kênh liên lạc nào hiện đang được sử dụng để truy cập Internet. Tôi đã kiểm tra và nó bật ra như vậy. Có nhiều tuyến đường khác nhau khi truy tìm. 

system(“tracert -d -w 500 8.8.8.8”);

Vì vậy, một tập lệnh khác xuất hiện, hay nói đúng hơn là vì lý do nào đó, dấu vết đã được thêm vào cuối tập lệnh tương tự, khiến ping tất cả các thiết bị trên mạng. Rốt cuộc, đây là một quá trình dài khác được thực thi trong cùng một luồng và làm chậm công việc của toàn bộ tập lệnh. Nhưng sau đó nó không quá rõ ràng. Nhưng bằng cách này hay cách khác, anh ấy đã thực hiện công việc của mình, mã đã xác định nghiêm ngặt loại hình theo dõi nào sẽ dành cho từng kênh. Đây là cách hệ thống bắt đầu hoạt động, hệ thống đã được giám sát (nói to, vì không có bộ sưu tập bất kỳ số liệu nào mà chỉ ping) các thiết bị mạng (bộ định tuyến, bộ chuyển mạch, wi-fi, v.v.) và các kênh liên lạc với thế giới bên ngoài . Tin nhắn SMS đến thường xuyên và sơ đồ luôn chỉ rõ vấn đề nằm ở đâu.

Hơn nữa, trong công việc hàng ngày tôi phải vượt biên. Và tôi cảm thấy mệt mỏi khi mỗi lần phải đến các thiết bị chuyển mạch của Cisco để xem nên sử dụng giao diện nào. Sẽ thật tuyệt biết bao khi nhấp vào một đối tượng đang theo dõi và xem danh sách các giao diện của nó kèm theo mô tả. Nó sẽ giúp tôi tiết kiệm thời gian. Hơn nữa, trong sơ đồ này sẽ không cần chạy PuTTY hoặc SecureCRT để nhập tài khoản và lệnh. Tôi chỉ cần nhấp vào theo dõi, xem những gì cần thiết và đi làm công việc của mình. Tôi bắt đầu tìm cách tương tác với switch. Ngay lập tức tôi thấy 2 lựa chọn: SNMP hoặc đăng nhập vào switch qua SSH, nhập các lệnh tôi cần và phân tích kết quả. Tôi đã loại bỏ SNMP vì sự phức tạp trong việc triển khai nó; tôi rất nóng lòng muốn nhận được kết quả. với SNMP, bạn sẽ phải tìm hiểu MIB trong một thời gian dài và dựa trên dữ liệu này để tạo dữ liệu về các giao diện. Có một đội ngũ tuyệt vời tại CISCO 

show interface status

Nó hiển thị chính xác những gì tôi cần cho việc vượt biên. Tôi nghĩ tại sao phải bận tâm đến SNMP khi tôi chỉ muốn xem đầu ra của lệnh này. Sau một thời gian, tôi nhận ra cơ hội này. Nhấp chuột vào một đối tượng trên một trang web. Một sự kiện đã được kích hoạt trong đó máy khách AJAX liên hệ với máy chủ và đến lượt nó, được kết nối qua SSH với công tắc mà tôi cần (thông tin xác thực đã được mã hóa cứng thành mã, tôi không muốn tinh chỉnh nó, để tạo một số menu riêng biệt trong đó Có thể thay đổi tài khoản từ giao diện, tôi cần kết quả và nhanh chóng) Tôi nhập lệnh trên vào đó và gửi lại trình duyệt. Vì vậy, tôi bắt đầu xem thông tin về giao diện chỉ bằng một cú nhấp chuột. Điều này cực kỳ thuận tiện, đặc biệt khi bạn phải xem thông tin này trên các thiết bị chuyển mạch khác nhau cùng một lúc.

Giám sát kênh dựa trên dấu vết cuối cùng không phải là ý tưởng hay nhất, bởi vì... đôi khi công việc được thực hiện trên mạng và việc theo dõi có thể thay đổi và việc giám sát bắt đầu hét vào mặt tôi rằng có vấn đề với kênh. Nhưng sau khi dành nhiều thời gian để phân tích, tôi nhận ra rằng tất cả các kênh đều đang hoạt động và việc giám sát đang đánh lừa tôi. Do đó, tôi đã yêu cầu các đồng nghiệp quản lý các thiết bị chuyển mạch hình thành kênh chỉ cần gửi cho tôi nhật ký hệ thống khi trạng thái hiển thị của hàng xóm thay đổi. Theo đó, nó đơn giản hơn, nhanh hơn và chính xác hơn nhiều so với việc truy tìm. Một sự kiện như hàng xóm bị mất đã đến và tôi ngay lập tức đưa ra thông báo về việc kênh bị hỏng.

Hơn nữa, một số lệnh khác xuất hiện khi nhấp vào một đối tượng và SNMP đã được thêm vào để thu thập một số số liệu và về cơ bản là như vậy. Hệ thống không bao giờ phát triển hơn nữa. Nó làm được mọi thứ tôi cần, nó là một công cụ tốt. Nhiều độc giả có thể sẽ nói với tôi rằng trên Internet đã có rất nhiều phần mềm giải quyết những vấn đề này. Nhưng trên thực tế, hồi đó tôi chưa google những sản phẩm miễn phí như vậy và tôi thực sự muốn phát triển kỹ năng lập trình của mình và còn cách nào tốt hơn để thúc đẩy điều này hơn là giải quyết một vấn đề ứng dụng thực sự. Đến thời điểm này, phiên bản giám sát đầu tiên đã hoàn thành và không còn bị sửa đổi nữa.

Thành lập công ty Kiểm toán - Viễn thông

Thời gian trôi qua, tôi bắt đầu làm việc bán thời gian ở các công ty khác, may mắn thay lịch làm việc cho phép tôi làm điều này. Khi bạn làm việc ở các công ty khác nhau, kỹ năng của bạn trong các lĩnh vực khác nhau sẽ phát triển rất nhanh và tầm nhìn của bạn cũng phát triển tốt. Có những công ty mà ở đó, như người ta nói, bạn là người Thụy Điển, thợ gặt và người chơi kèn. Một mặt thì khó, mặt khác, nếu không lười biếng, bạn sẽ trở thành người tổng quát và điều này cho phép bạn giải quyết vấn đề nhanh hơn và hiệu quả hơn vì bạn biết lĩnh vực liên quan hoạt động như thế nào.

Bạn tôi, Pavel (cũng là chuyên gia CNTT) liên tục khuyến khích tôi khởi nghiệp kinh doanh riêng. Có vô số ý tưởng với những biến thể khác nhau của những gì họ đang làm. Điều này đã được thảo luận trong nhiều năm. Và cuối cùng, mọi chuyện lẽ ra không thành công gì cả vì tôi là người hay hoài nghi, còn Pavel là người mơ mộng. Mỗi lần anh ấy đề xuất ý tưởng, tôi luôn không tin và từ chối tham gia. Nhưng chúng tôi thực sự muốn mở doanh nghiệp của riêng mình.

Cuối cùng, chúng tôi đã tìm được một phương án phù hợp với cả hai và làm những gì chúng tôi biết cách làm. Năm 2016, chúng tôi quyết định thành lập một công ty CNTT giúp các doanh nghiệp giải quyết các vấn đề về CNTT. Đây là việc triển khai các hệ thống CNTT (1C, máy chủ đầu cuối, máy chủ thư, v.v.), bảo trì, HelpDesk cổ điển cho người dùng và quản trị mạng.

Thành thật mà nói, vào thời điểm thành lập công ty, tôi không tin vào điều đó khoảng 99,9%. Nhưng bằng cách nào đó Pavel đã thuyết phục được tôi thử, và nhìn về phía trước, hóa ra anh ấy đã đúng. Pavel và tôi góp 300 rúp mỗi người, đăng ký một LLC “Kiểm toán-Telecom” mới, thuê một văn phòng nhỏ, làm những tấm danh thiếp thú vị, nói chung, giống như hầu hết những doanh nhân mới vào nghề, thiếu kinh nghiệm và bắt đầu tìm kiếm khách hàng. Tìm kiếm khách hàng lại là một câu chuyện hoàn toàn khác. Có lẽ chúng tôi sẽ viết một bài riêng như một phần blog của công ty nếu có ai quan tâm. Cuộc gọi lạnh, tờ rơi, v.v. Điều này không mang lại bất kỳ kết quả nào. Như tôi đã đọc bây giờ từ nhiều câu chuyện về kinh doanh, bằng cách này hay cách khác, rất nhiều điều phụ thuộc vào may mắn. Chúng tôi đã may mắn. và theo đúng nghĩa đen là vài tuần sau khi thành lập công ty, anh trai Vladimir của tôi đã tiếp cận chúng tôi, người đã mang đến cho chúng tôi khách hàng đầu tiên. Tôi sẽ không làm bạn nhàm chán với các chi tiết làm việc với khách hàng, đó không phải là nội dung của bài báo, tôi sẽ chỉ nói rằng chúng tôi đã đi kiểm tra, xác định các khu vực quan trọng và những khu vực này đã bị hỏng trong khi quyết định được đưa ra về việc có nên làm hay không hợp tác liên tục với chúng tôi với tư cách là người đăng việc. Sau đó, một quyết định tích cực ngay lập tức được đưa ra.

Sau đó, chủ yếu thông qua truyền miệng qua bạn bè, các công ty dịch vụ khác bắt đầu xuất hiện. Bộ phận trợ giúp nằm trong một hệ thống. Các kết nối với thiết bị mạng và máy chủ là khác nhau, hay đúng hơn là khác nhau. Một số người đã lưu phím tắt, những người khác sử dụng sổ địa chỉ RDP. Giám sát là một hệ thống riêng biệt khác. Rất bất tiện cho một nhóm làm việc trong các hệ thống khác nhau. Thông tin quan trọng bị mất tầm nhìn. Vâng, ví dụ, máy chủ đầu cuối của khách hàng không khả dụng. Các ứng dụng từ người dùng của khách hàng này sẽ được nhận ngay lập tức. Chuyên gia hỗ trợ mở một yêu cầu (đã nhận được qua điện thoại). Nếu sự cố và yêu cầu được đăng ký trong một hệ thống, thì chuyên gia hỗ trợ sẽ ngay lập tức xem vấn đề của người dùng là gì và thông báo cho họ về vấn đề đó, đồng thời kết nối với đối tượng được yêu cầu để giải quyết tình huống. Mọi người đều nắm rõ tình hình chiến thuật và phối hợp nhịp nhàng. Chúng tôi chưa tìm thấy một hệ thống nào có thể kết hợp tất cả những điều này. Rõ ràng đã đến lúc chúng tôi phải tạo ra sản phẩm của riêng mình.

Tiếp tục làm việc trên hệ thống giám sát của bạn

Rõ ràng là hệ thống được viết trước đó hoàn toàn không phù hợp với nhiệm vụ hiện tại. Cả về chức năng lẫn chất lượng. Và người ta quyết định viết hệ thống từ đầu. Về mặt đồ họa, lẽ ra nó phải trông hoàn toàn khác. Nó phải là một hệ thống phân cấp để có thể mở đúng đối tượng cho đúng khách hàng một cách nhanh chóng và thuận tiện. Sơ đồ như trong phiên bản đầu tiên hoàn toàn không hợp lý trong trường hợp hiện tại, bởi vì Các khách hàng là khác nhau và việc đặt thiết bị ở cơ sở nào không quan trọng. Điều này đã được chuyển vào tài liệu.

Vì vậy, các nhiệm vụ:

  1. Cấu trúc phân cấp;
  2. Một số loại bộ phận máy chủ có thể được đặt tại cơ sở của khách hàng dưới dạng máy ảo để thu thập các số liệu chúng tôi cần và gửi đến máy chủ trung tâm, máy chủ này sẽ tóm tắt tất cả những điều này và hiển thị cho chúng tôi;
  3. Cảnh báo. Những điều không thể bỏ qua, bởi... lúc đó không thể có người ngồi và chỉ nhìn vào màn hình;
  4. Hệ thống ứng dụng. Bắt đầu xuất hiện những khách hàng mà chúng tôi phục vụ không chỉ máy chủ và thiết bị mạng mà còn cả máy trạm;
  5. Khả năng kết nối nhanh chóng với máy chủ và thiết bị từ hệ thống;

Các nhiệm vụ đã được đặt ra, chúng tôi bắt đầu viết. Trên đường đi, xử lý các yêu cầu từ khách hàng. Lúc đó chúng tôi đã có 4 người rồi. Chúng tôi bắt đầu viết cả hai phần cùng một lúc: máy chủ trung tâm và máy chủ để cài đặt cho máy khách. Đến thời điểm này, Linux không còn xa lạ với chúng ta nữa và người ta đã quyết định rằng các máy ảo mà khách hàng có sẽ sử dụng Debian. Sẽ không có trình cài đặt, chúng tôi sẽ chỉ tạo một dự án phần máy chủ trên một máy ảo cụ thể và sau đó chúng tôi sẽ sao chép nó vào máy khách mong muốn. Đây là một sai lầm khác. Sau đó, rõ ràng là trong sơ đồ như vậy, cơ chế cập nhật hoàn toàn chưa được phát triển. Những thứ kia. chúng tôi đã thêm một số tính năng mới và sau đó xảy ra toàn bộ vấn đề khi phân phối nó đến tất cả các máy chủ khách, nhưng chúng tôi sẽ quay lại vấn đề này sau, mọi thứ đều theo thứ tự.

Chúng tôi đã tạo ra nguyên mẫu đầu tiên. Anh ấy có thể ping các thiết bị mạng khách và máy chủ mà chúng tôi cần và gửi dữ liệu này đến máy chủ trung tâm của chúng tôi. Và đến lượt anh ta đã cập nhật hàng loạt dữ liệu này trên máy chủ trung tâm. Ở đây tôi sẽ không chỉ viết một câu chuyện về cách thức và điều gì đã thành công mà còn cả những sai lầm nghiệp dư đã mắc phải và sau này tôi đã phải trả giá như thế nào theo thời gian. Vì vậy, toàn bộ cây đối tượng được lưu trữ trong một tệp duy nhất dưới dạng đối tượng được tuần tự hóa. Trong khi chúng tôi kết nối một số máy khách với hệ thống, mọi thứ ít nhiều vẫn bình thường, mặc dù đôi khi có một số hiện vật hoàn toàn không thể hiểu được. Nhưng khi chúng tôi kết nối hàng chục máy chủ vào hệ thống, điều kỳ diệu bắt đầu xảy ra. Đôi khi, vì một lý do không xác định nào đó, tất cả các đối tượng trong hệ thống đều biến mất. Điều quan trọng cần lưu ý ở đây là các máy chủ mà khách hàng đã gửi dữ liệu đến máy chủ trung tâm cứ sau vài giây thông qua yêu cầu POST. Một người đọc chăm chú và một lập trình viên có kinh nghiệm đã đoán rằng có một vấn đề với nhiều quyền truy cập vào chính tệp trong đó đối tượng được tuần tự hóa được lưu trữ từ các luồng khác nhau cùng một lúc. Và ngay khi điều này đang xảy ra, điều kỳ diệu đã xảy ra với sự biến mất của đồ vật. Đơn giản là tập tin đã trở nên trống rỗng. Nhưng tất cả điều này không được phát hiện ngay lập tức mà chỉ trong quá trình hoạt động với một số máy chủ. Trong thời gian này, chức năng quét cổng đã được thêm vào (các máy chủ gửi đến trung tâm không chỉ thông tin về tính khả dụng của thiết bị mà còn về các cổng mở trên chúng). Điều này được thực hiện bằng cách gọi lệnh:

$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);

kết quả thường không chính xác và quá trình quét mất nhiều thời gian để hoàn thành. Tôi hoàn toàn quên mất ping, nó được thực hiện thông qua fping:

system("fping -r 3 -t 100 {$this->ip}");

Quá trình này cũng không được thực hiện song song và do đó quá trình này rất dài. Sau đó, toàn bộ danh sách các địa chỉ IP cần thiết để xác minh đã được gửi tới fping cùng một lúc và chúng tôi nhận được danh sách tạo sẵn gồm những người đã phản hồi. Không giống như chúng tôi, fping có thể song song hóa các quy trình.

Một công việc thường ngày phổ biến khác là thiết lập một số dịch vụ qua WEB. Vâng, ví dụ, ECP từ MS Exchange. Về cơ bản nó chỉ là một liên kết. Và chúng tôi quyết định rằng chúng tôi cần có khả năng thêm các liên kết như vậy trực tiếp vào hệ thống để không phải xem tài liệu hoặc nơi nào khác trong dấu trang để biết cách truy cập ECP của một khách hàng cụ thể. Đây là cách mà khái niệm liên kết tài nguyên cho hệ thống xuất hiện, chức năng của chúng vẫn tồn tại cho đến ngày nay và gần như không thay đổi.

Cách liên kết tài nguyên hoạt động trong Veliam
Từ outsourcing đến phát triển (Phần 1)

Kết nối từ xa

Đây là giao diện hoạt động của phiên bản hiện tại của Veliam
Từ outsourcing đến phát triển (Phần 1)

Một trong những nhiệm vụ là kết nối nhanh chóng và thuận tiện với các máy chủ, vốn đã có rất nhiều (hơn một trăm) và việc sắp xếp hàng triệu phím tắt RDP được lưu trước là vô cùng bất tiện. Một công cụ là cần thiết. Có một phần mềm trên Internet giống như sổ địa chỉ cho các kết nối RDP như vậy, nhưng chúng không được tích hợp với hệ thống giám sát và không thể lưu tài khoản. Việc nhập tài khoản cho các khách hàng khác nhau mỗi lần thực sự là một địa ngục khi bạn kết nối hàng chục lần một ngày với các máy chủ khác nhau. Với SSH, mọi thứ tốt hơn một chút; có rất nhiều phần mềm tốt cho phép bạn sắp xếp các kết nối như vậy vào các thư mục và ghi nhớ các tài khoản từ chúng. Nhưng có 2 vấn đề. Đầu tiên là chúng tôi không tìm thấy một chương trình nào cho kết nối RDP và SSH. Thứ hai là nếu một lúc nào đó tôi không ở bên máy tính và cần kết nối nhanh hoặc tôi vừa cài đặt lại hệ thống, tôi sẽ phải vào tài liệu để xem tài khoản từ khách hàng này. Thật bất tiện và lãng phí thời gian.

Cấu trúc phân cấp mà chúng tôi cần cho máy chủ khách đã có sẵn trong sản phẩm nội bộ của chúng tôi. Tôi chỉ phải tìm cách gắn kết nối nhanh với các thiết bị cần thiết ở đó. Để bắt đầu, ít nhất là trong mạng của bạn.

Có tính đến thực tế rằng ứng dụng khách trong hệ thống của chúng tôi là một trình duyệt không có quyền truy cập vào tài nguyên cục bộ của máy tính, để chỉ cần khởi chạy ứng dụng mà chúng tôi cần bằng một số lệnh, nó đã được phát minh để thực hiện mọi thứ thông qua “Windows lược đồ url tùy chỉnh”. Đây là cách một “plugin” nhất định xuất hiện cho hệ thống của chúng tôi, chỉ bao gồm PuTTY và Remote Desktop Plus và trong quá trình cài đặt, chỉ cần đăng ký lược đồ URI trong Windows. Bây giờ, khi chúng tôi muốn kết nối với một đối tượng thông qua RDP hoặc SSH, chúng tôi đã nhấp vào hành động này trên hệ thống của mình và URI tùy chỉnh đã hoạt động. Mstsc.exe tiêu chuẩn được tích hợp trong Windows hoặc PuTTY, là một phần của “plugin”, đã được ra mắt. Tôi đặt từ plugin trong dấu ngoặc kép vì đây không phải là plugin trình duyệt theo nghĩa cổ điển.

Ít nhất đó là một cái gì đó. Sổ địa chỉ tiện lợi. Hơn nữa, trong trường hợp của Putty, mọi thứ nhìn chung đều ổn; nó có thể được cung cấp kết nối IP, thông tin đăng nhập và mật khẩu làm tham số đầu vào. Những thứ kia. Chúng tôi đã kết nối với máy chủ Linux trên mạng của mình chỉ bằng một cú nhấp chuột mà không cần nhập mật khẩu. Nhưng với RDP thì không đơn giản như vậy. Mstsc tiêu chuẩn không thể cung cấp thông tin xác thực làm tham số. Remote Desktop Plus đã ra tay giải cứu. Anh ấy đã cho phép điều này xảy ra. Bây giờ chúng tôi có thể làm mà không cần nó, nhưng trong một thời gian dài nó đã là một trợ lý trung thành trong hệ thống của chúng tôi. Với các trang HTTP(S), mọi thứ đều đơn giản, những đối tượng như vậy chỉ cần mở trong trình duyệt và thế là xong. Thuận tiện và thiết thực. Nhưng đây chỉ là hạnh phúc trên mạng nội bộ.

Vì chúng tôi đã giải quyết phần lớn các vấn đề từ xa văn phòng nên điều dễ dàng nhất là cung cấp VPN cho khách hàng. Và sau đó có thể kết nối với họ từ hệ thống của chúng tôi. Nhưng nó vẫn có phần bất tiện. Đối với mỗi máy khách, cần phải giữ một loạt kết nối VPN được ghi nhớ trên mỗi máy tính và trước khi kết nối với bất kỳ máy tính nào, cần phải kích hoạt VPN tương ứng. Chúng tôi đã sử dụng giải pháp này trong một thời gian khá dài. Nhưng số lượng khách hàng ngày càng tăng, số lượng VPN cũng ngày càng tăng, và tất cả những điều này bắt đầu trở nên căng thẳng và phải làm gì đó để giải quyết nó. Tôi đặc biệt rơi nước mắt sau khi cài đặt lại hệ thống, khi tôi phải nhập lại hàng tá kết nối VPN trong cấu hình Windows mới. Đừng chịu đựng chuyện này nữa, tôi nói, và bắt đầu nghĩ xem mình có thể làm gì với nó.

Điều đó đã xảy ra khi tất cả khách hàng đều có thiết bị của công ty nổi tiếng Mikrotik làm bộ định tuyến. Chúng rất tiện dụng và thuận tiện để thực hiện hầu hết mọi nhiệm vụ. Nhược điểm là chúng bị “chiếm quyền điều khiển”. Chúng tôi đã giải quyết vấn đề này một cách đơn giản bằng cách đóng tất cả quyền truy cập từ bên ngoài. Nhưng bằng cách nào đó cần phải có quyền truy cập vào chúng mà không cần đến chỗ của khách hàng, bởi vì... nó dài. Chúng tôi chỉ đơn giản là tạo đường hầm cho mỗi chiếc Mikrotik như vậy và tách chúng thành một nhóm riêng biệt. không có bất kỳ định tuyến nào, do đó không có kết nối mạng của bạn với mạng của khách hàng và mạng của họ với nhau.

Ý tưởng này ra đời nhằm đảm bảo rằng khi tôi nhấp vào đối tượng tôi cần trong hệ thống, máy chủ giám sát trung tâm, biết tài khoản SSH của tất cả khách hàng Mikrotik, sẽ kết nối với đối tượng mong muốn, tạo quy tắc chuyển tiếp đến máy chủ mong muốn bằng cổng cần thiết. Có một số điểm ở đây. Giải pháp này không phổ biến - nó sẽ chỉ hoạt động với Mikrotik, vì cú pháp lệnh khác nhau đối với tất cả các bộ định tuyến. Ngoài ra, bằng cách nào đó, các chuyển tiếp như vậy phải bị xóa và phần máy chủ trong hệ thống của chúng tôi về cơ bản không thể theo dõi xem tôi đã hoàn thành phiên RDP của mình hay chưa. Vâng, việc chuyển tiếp như vậy là một lỗ hổng cho khách hàng. Nhưng chúng tôi không theo đuổi tính phổ quát, bởi vì... sản phẩm chỉ được sử dụng trong công ty chúng tôi và không có ý định phát hành nó ra công chúng.

Mỗi vấn đề đã được giải quyết theo cách riêng của nó. Khi quy tắc được tạo, việc chuyển tiếp này chỉ khả dụng cho một địa chỉ IP bên ngoài cụ thể (từ đó kết nối được khởi tạo). Vì vậy, một lỗ hổng bảo mật đã tránh được. Nhưng với mỗi kết nối như vậy, quy tắc Mikrotik đã được thêm vào trang NAT và không bị xóa. Và mọi người đều biết rằng càng có nhiều quy tắc thì bộ xử lý của bộ định tuyến càng được tải nhiều. Và nói chung, tôi không thể chấp nhận rằng một ngày nào đó tôi sẽ đến Mikrotik nào đó và sẽ có hàng trăm quy tắc chết chóc, vô dụng.

Vì máy chủ của chúng tôi không thể theo dõi trạng thái kết nối nên hãy để Mikrotik tự theo dõi chúng. Và tôi đã viết một tập lệnh liên tục theo dõi tất cả các quy tắc chuyển tiếp bằng một mô tả cụ thể và kiểm tra xem kết nối TCP có quy tắc phù hợp hay không. Nếu không có kết nối nào trong một thời gian thì có thể kết nối đã được hoàn tất và việc chuyển tiếp này có thể bị xóa. Mọi thứ đều ổn, kịch bản hoạt động tốt.

Nhân tiện, đây là:

global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={ 
	local dstport [/ip firewall nat get value-name="dst-port" $i]
	local dstaddress [/ip firewall nat get value-name="dst-address" $i]
	local dstaddrport "$dstaddress:$dstport"
	#log warning message=$dstaddrport
	local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
	if ($thereIsCon = "") do={
		set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
		#:log warning message=($atmonrulecounter->$dstport)
		if (($atmonrulecounter->$dstport) > 5) do={
			#log warning message="Removing nat rules added automaticaly by atmon_script"
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
			/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
			set ($atmonrulecounter->$dstport) 0
		}
	} else {
		set ($atmonrulecounter->$dstport) 0
	}
}

Chắc chắn nó có thể được làm đẹp hơn, nhanh hơn, v.v., nhưng nó đã hoạt động, không tải Mikrotik và hoàn thành xuất sắc công việc. Cuối cùng chúng tôi đã có thể kết nối với máy chủ và thiết bị mạng của khách hàng chỉ bằng một cú nhấp chuột. Không cần mở VPN hoặc nhập mật khẩu. Hệ thống đã trở nên thực sự thuận tiện để làm việc. Thời gian phục vụ giảm xuống và tất cả chúng tôi đều dành thời gian cho công việc thay vì kết nối với những đồ vật cần thiết.

Sao lưu Mikrotik

Chúng tôi đã định cấu hình sao lưu tất cả Mikrotik sang FTP. Và nhìn chung mọi thứ đều ổn. Nhưng khi cần sao lưu, bạn phải mở FTP này và tìm nó ở đó. Chúng tôi có một hệ thống nơi tất cả các bộ định tuyến được kết nối; chúng tôi có thể giao tiếp với các thiết bị thông qua SSH. Tôi nghĩ tại sao chúng ta không làm điều đó để hệ thống tự sao lưu từ tất cả Mikrotik hàng ngày. Và anh bắt đầu thực hiện nó. Chúng tôi đã kết nối, tạo bản sao lưu và đưa nó vào bộ lưu trữ.

Mã tập lệnh bằng PHP để sao lưu từ Mikrotik:

<?php

	$IP = '0.0.0.0';
	$LOGIN = 'admin';
	$PASSWORD = '';
	$BACKUP_NAME = 'test';

    $connection = ssh2_connect($IP, 22);

    if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;

    ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
    stream_get_contents($connection);
    ssh2_exec($connection, '/export file="atmon.rsc"');
    stream_get_contents($connection);
    sleep(40); // Waiting bakup makes

    $sftp = ssh2_sftp($connection);

    // Download backup file
    $size = filesize("ssh2.sftp://$sftp/atmon.backup");
    $stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
    @fclose($stream);

    sleep(3);
    // Download RSC file
    $size = filesize("ssh2.sftp://$sftp/atmon.rsc");
    $stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
    $contents = '';
    $read = 0;
    $len = $size;
    while ($read < $len && ($buf = fread($stream, $len - $read))) {
        $read += strlen($buf);
        $contents .= $buf;
    }
    file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
    @fclose($stream);

    ssh2_exec($connection, '/file remove atmon.backup');
    ssh2_exec($connection, '/file remove atmon.rsc');

?>

Việc sao lưu được thực hiện dưới hai dạng - cấu hình nhị phân và văn bản. Tệp nhị phân giúp khôi phục nhanh chóng cấu hình được yêu cầu và tệp nhị phân cho phép bạn hiểu những gì cần phải làm nếu buộc phải thay thế thiết bị và không thể tải tệp nhị phân lên đó. Kết quả là chúng tôi có được một chức năng tiện lợi khác trong hệ thống. Hơn nữa, khi thêm Mikrotik mới, không cần phải cấu hình gì cả, tôi chỉ cần thêm đối tượng vào hệ thống và thiết lập tài khoản cho nó thông qua SSH. Sau đó, hệ thống tự đảm nhiệm việc sao lưu. Phiên bản hiện tại của SaaS Veliam chưa có chức năng này nhưng chúng tôi sẽ sớm chuyển nó.

Ảnh chụp màn hình về giao diện của nó trong hệ thống nội bộ
Từ outsourcing đến phát triển (Phần 1)

Chuyển sang lưu trữ cơ sở dữ liệu thông thường

Tôi đã viết ở trên rằng hiện vật đã xuất hiện. Đôi khi toàn bộ danh sách các đối tượng trong hệ thống biến mất, đôi khi khi chỉnh sửa một đối tượng, thông tin không được lưu và đối tượng phải đổi tên ba lần. Điều này khiến mọi người vô cùng khó chịu. Sự biến mất của các đối tượng hiếm khi xảy ra và có thể dễ dàng khôi phục bằng cách khôi phục chính tệp này, nhưng lỗi khi chỉnh sửa đối tượng xảy ra khá thường xuyên. Có lẽ, ban đầu tôi không làm điều này thông qua cơ sở dữ liệu vì trong đầu tôi không nghĩ đến việc làm thế nào có thể giữ một cái cây với tất cả các kết nối trong một bảng phẳng. Nó phẳng, nhưng cây có thứ bậc. Nhưng một giải pháp tốt cho đa truy cập và sau đó là giao dịch (khi hệ thống trở nên phức tạp hơn) là DBMS. Tôi có lẽ không phải là người đầu tiên gặp phải vấn đề này. Tôi bắt đầu tra cứu trên Google. Hóa ra mọi thứ đều đã được phát minh ra trước tôi và có một số thuật toán xây dựng một cái cây từ một chiếc bàn phẳng. Sau khi xem xét từng cái, tôi đã thực hiện một trong số chúng. Nhưng đây đã là phiên bản mới của hệ thống rồi, bởi vì... Thực sự vì điều này mà tôi đã phải viết lại khá nhiều. Kết quả là tự nhiên, các vấn đề về hành vi ngẫu nhiên của hệ thống đã biến mất. Một số người có thể nói rằng các lỗi rất nghiệp dư (các tập lệnh đơn luồng, lưu trữ thông tin được truy cập đồng thời nhiều lần từ các luồng khác nhau trong một tệp, v.v.) trong lĩnh vực phát triển phần mềm. Có lẽ điều này đúng, nhưng công việc chính của tôi là quản trị, và lập trình là một nghề phụ trong tâm hồn tôi, và đơn giản là tôi không có kinh nghiệm làm việc trong một nhóm lập trình viên, nơi mà những điều cơ bản như vậy sẽ được cấp trên gợi ý ngay cho tôi. các đồng chí. Vì vậy, tôi đã tự mình lấp đầy tất cả những khúc mắc này nhưng tôi đã học rất tốt tài liệu. Ngoài ra, công việc của tôi còn liên quan đến các cuộc gặp gỡ với khách hàng, các hoạt động nhằm cố gắng quảng bá công ty, một loạt các vấn đề hành chính trong công ty, v.v. Nhưng bằng cách này hay cách khác, những gì đã có đều có nhu cầu. Bản thân tôi và các bạn đã sử dụng sản phẩm trong công việc hàng ngày. Thực sự đã có những ý tưởng và giải pháp không thành công khiến thời gian bị lãng phí, nhưng cuối cùng, rõ ràng đây không phải là một công cụ làm việc và không ai sử dụng nó và nó không có mặt ở Veliam.

Bộ phận trợ giúp - HelpDesk

Sẽ không sai khi đề cập đến cách HelpDesk được hình thành. Đây là một câu chuyện hoàn toàn khác, bởi vì... ở Veliam đây đã là phiên bản hoàn toàn mới thứ 3, khác với tất cả các phiên bản trước. Giờ đây, nó là một hệ thống đơn giản, trực quan, không có chuông và còi không cần thiết, với khả năng tích hợp với một miền cũng như khả năng truy cập vào cùng một hồ sơ người dùng từ mọi nơi bằng cách sử dụng liên kết từ email. Và quan trọng nhất, có thể kết nối với người nộp đơn qua VNC từ mọi nơi (tại nhà hoặc tại văn phòng) trực tiếp từ ứng dụng mà không cần chuyển tiếp VPN hoặc cổng. Tôi sẽ kể cho bạn biết chúng tôi đã đạt được điều này như thế nào, điều gì đã xảy ra trước đây và những quyết định khủng khiếp nào đã được đưa ra.

Chúng tôi đã kết nối với người dùng thông qua TeamViewer nổi tiếng. Tất cả các máy tính mà người dùng chúng tôi phục vụ đều đã cài đặt TV. Điều đầu tiên chúng tôi đã làm sai và sau đó đã xóa nó là liên kết từng máy khách HD với phần cứng. Người dùng đăng nhập vào hệ thống HD để gửi yêu cầu bằng cách nào? Ngoài TV, mọi người đều cài đặt một tiện ích đặc biệt trên máy tính của mình, được viết bằng Lazarus (nhiều người ở đây sẽ tròn mắt và thậm chí có thể tra Google xem nó là gì, nhưng ngôn ngữ được biên dịch tốt nhất mà tôi biết là Delphi, và Lazarus gần như là điều tương tự, chỉ miễn phí). Nói chung, người dùng đã khởi chạy một tệp bó đặc biệt để khởi chạy tiện ích này, tiện ích này lần lượt đọc HWID của hệ thống và sau đó trình duyệt được khởi chạy và quá trình ủy quyền diễn ra. Tại sao điều này được thực hiện? Ở một số công ty, số lượng người dùng dịch vụ được tính riêng lẻ và giá dịch vụ mỗi tháng được tính theo số lượng người. Bạn nói điều này có thể hiểu được, nhưng tại sao nó lại gắn liền với phần cứng? Rất đơn giản, một số người về nhà và đưa ra yêu cầu từ máy tính xách tay ở nhà theo kiểu “ở đây hãy làm mọi thứ thật đẹp cho tôi”. Ngoài việc đọc HWID hệ thống, tiện ích này còn lấy ID Teamviewer hiện tại khỏi sổ đăng ký và truyền cho chúng tôi. Teamviewer có API để tích hợp. Và chúng tôi đã thực hiện sự tích hợp này. Nhưng có một nhược điểm. Thông qua các API này, không thể kết nối với máy tính của người dùng khi anh ta không bắt đầu phiên này một cách rõ ràng và sau khi cố gắng kết nối với nó, anh ta cũng phải nhấp vào “xác nhận”. Vào thời điểm đó, đối với chúng tôi, có vẻ hợp lý là không ai được phép kết nối nếu không có yêu cầu của người dùng và vì người đó đang ở trên máy tính nên anh ta sẽ bắt đầu phiên và phản hồi tích cực đối với yêu cầu kết nối từ xa. Mọi thứ trở nên sai lầm. Các ứng viên đã quên nhấn nút bắt đầu buổi phỏng vấn và phải nói với họ điều này qua một cuộc trò chuyện qua điện thoại. Điều này lãng phí thời gian và gây khó chịu cho cả hai phía của quá trình. Hơn nữa, không có gì lạ khi một người để lại yêu cầu nhưng chỉ được phép kết nối khi anh ta đi ăn trưa. Vì vấn đề không nghiêm trọng và anh không muốn quá trình làm việc của mình bị gián đoạn. Theo đó, anh ta sẽ không nhấn bất kỳ nút nào để cho phép kết nối. Đây là cách chức năng bổ sung xuất hiện khi đăng nhập vào HelpDesk - đọc ID của Teamviwer. Chúng tôi biết mật khẩu cố định được sử dụng khi cài đặt Teamviwer. Chính xác hơn, chỉ có hệ thống mới biết điều đó, vì nó đã được tích hợp sẵn trong trình cài đặt và vào hệ thống của chúng tôi. Theo đó, đã có nút kết nối từ ứng dụng khi bấm vào không cần phải chờ đợi gì nhưng Teamviewer đã ngay lập tức mở ra và xảy ra kết nối. Kết quả là có hai loại kết nối có thể xảy ra. Thông qua API Teamviewer chính thức và API tự tạo của chúng tôi. Trước sự ngạc nhiên của tôi, họ đã ngừng sử dụng cái đầu tiên gần như ngay lập tức, mặc dù có hướng dẫn chỉ sử dụng nó trong những trường hợp đặc biệt và khi chính người dùng cho phép. Tuy nhiên, hãy cho tôi sự an toàn ngay bây giờ. Nhưng hóa ra người nộp đơn không cần điều này. Tất cả đều hoàn toàn ổn khi được kết nối với chúng mà không cần nút xác nhận.

Chuyển sang đa luồng trong Linux

Câu hỏi về việc tăng tốc độ quét mạng để mở danh sách cổng được xác định trước và ping đơn giản các đối tượng mạng đã bắt đầu nảy sinh từ lâu. Tất nhiên, ở đây, giải pháp đầu tiên tôi nghĩ đến là đa luồng. Vì thời gian chính dành cho ping là chờ gói được trả lại và ping tiếp theo không thể bắt đầu cho đến khi gói trước đó được trả lại, ở những công ty thậm chí có hơn 20 máy chủ cộng với thiết bị mạng, điều này đã hoạt động khá chậm. Vấn đề là một gói có thể biến mất nhưng không thông báo ngay cho quản trị viên hệ thống về nó. Đơn giản là anh ta sẽ ngừng chấp nhận những thư rác như vậy rất nhanh chóng. Điều này có nghĩa là bạn cần ping từng đối tượng nhiều lần trước khi đưa ra kết luận về khả năng không thể truy cập. Không đi sâu vào chi tiết, cần phải song song hóa nó vì nếu việc này không được thực hiện thì rất có thể quản trị viên hệ thống sẽ tìm hiểu về vấn đề từ máy khách chứ không phải từ hệ thống giám sát.

Bản thân PHP không hỗ trợ đa luồng. Có khả năng đa xử lý, bạn có thể phân nhánh. Nhưng trên thực tế, tôi đã viết sẵn một cơ chế bỏ phiếu và tôi muốn làm cho nó có thể đếm tất cả các nút tôi cần từ cơ sở dữ liệu, ping mọi thứ cùng một lúc, đợi phản hồi từ mỗi nút và chỉ sau đó mới viết ngay lập tức dữ liệu. Điều này tiết kiệm số lượng yêu cầu đọc. Đa luồng hoàn toàn phù hợp với ý tưởng này. Đối với PHP, có một mô-đun PThreads cho phép bạn thực hiện đa luồng thực sự, mặc dù phải mất khá nhiều thời gian mày mò để thiết lập tính năng này trên PHP 7.2, nhưng nó đã được thực hiện. Quét cổng và ping bây giờ nhanh chóng. Và thay vì, chẳng hạn như 15 giây mỗi vòng trước đó, quá trình này bắt đầu mất 2 giây. Đó là một kết quả tốt.

Kiểm toán nhanh các công ty mới

Chức năng thu thập các số liệu và đặc điểm phần cứng khác nhau ra đời như thế nào? Nó đơn giản. Đôi khi chúng tôi chỉ được yêu cầu kiểm tra cơ sở hạ tầng CNTT hiện tại. Chà, điều tương tự cũng cần thiết để tăng tốc quá trình kiểm tra khách hàng mới. Chúng tôi cần thứ gì đó cho phép chúng tôi tiếp cận một công ty vừa hoặc lớn và nhanh chóng tìm ra những gì họ có. Theo tôi, ping trên mạng nội bộ chỉ bị chặn bởi những người muốn làm phức tạp cuộc sống của chính họ và theo kinh nghiệm của chúng tôi thì có rất ít người trong số họ. Nhưng cũng có những người như vậy. Theo đó, bạn có thể nhanh chóng quét mạng để tìm sự hiện diện của thiết bị chỉ bằng một lệnh ping đơn giản. Sau đó, chúng tôi có thể thêm chúng và quét các cổng mở mà chúng tôi quan tâm. Trên thực tế, chức năng này đã tồn tại; chỉ cần thêm lệnh từ máy chủ trung tâm vào máy chủ phụ để nó quét các mạng được chỉ định và thêm mọi thứ nó tìm thấy vào danh sách. Tôi quên đề cập, người ta cho rằng chúng tôi đã có một hình ảnh làm sẵn với hệ thống được định cấu hình (máy chủ giám sát nô lệ) mà chúng tôi có thể chỉ cần triển khai từ máy khách trong quá trình kiểm tra và kết nối nó với đám mây của chúng tôi.

Nhưng kết quả kiểm tra thường bao gồm nhiều thông tin khác nhau và một trong số đó là loại thiết bị trên mạng. Trước hết, chúng tôi quan tâm đến máy chủ Windows và máy trạm Windows như một phần của miền. Vì ở các công ty vừa và lớn, việc thiếu tên miền có lẽ là một ngoại lệ đối với quy luật này. Theo tôi, để nói một ngôn ngữ, trung bình có hơn 100 người. Cần phải nghĩ ra cách thu thập dữ liệu từ tất cả các máy và máy chủ Windows, biết tài khoản quản trị viên miền và IP của chúng nhưng không cài đặt bất kỳ phần mềm nào trên mỗi máy và máy chủ đó. Giao diện WMI ra đời để giải cứu. Công cụ quản lý Windows (WMI) theo nghĩa đen có nghĩa là các công cụ quản lý Windows. WMI là một trong những công nghệ cơ bản để quản lý tập trung và giám sát hoạt động của các phần khác nhau của cơ sở hạ tầng máy tính chạy nền tảng Windows. Lấy từ wiki. Tiếp theo, tôi phải mày mò một lần nữa để biên dịch wmic (đây là máy khách WMI) cho Debian. Sau khi mọi thứ đã sẵn sàng, tất cả những gì còn lại chỉ là thăm dò các nút cần thiết thông qua wmic để biết thông tin cần thiết. Thông qua WMI, bạn có thể lấy hầu hết mọi thông tin từ máy tính Windows và hơn nữa, bạn cũng có thể điều khiển máy tính thông qua nó, chẳng hạn như gửi nó đi khởi động lại. Đây là cách thu thập thông tin về các trạm và máy chủ Windows trong hệ thống của chúng tôi xuất hiện. Ngoài ra, còn có thông tin hiện tại về các chỉ báo tải hệ thống hiện tại. Chúng tôi yêu cầu chúng thường xuyên hơn và thông tin về phần cứng ít thường xuyên hơn. Sau đó, việc kiểm toán trở nên thú vị hơn một chút.

Quyết định phân phối phần mềm

Bản thân chúng tôi sử dụng hệ thống này hàng ngày và nó luôn mở cho mọi nhân viên kỹ thuật. Và chúng tôi nghĩ rằng chúng tôi có thể chia sẻ với người khác những gì chúng tôi đã có. Hệ thống vẫn chưa sẵn sàng để được phân phối. Rất nhiều thứ phải được làm lại để phiên bản địa phương chuyển thành SaaS. Chúng bao gồm những thay đổi về các khía cạnh kỹ thuật khác nhau của hệ thống (kết nối từ xa, dịch vụ hỗ trợ), phân tích các mô-đun cấp phép, bảo vệ cơ sở dữ liệu khách hàng, mở rộng quy mô của từng dịch vụ và phát triển hệ thống tự động cập nhật cho tất cả các bộ phận. Nhưng đây sẽ là phần thứ hai của bài viết.

Cập nhật

Phần thứ hai

Nguồn: www.habr.com

Thêm một lời nhận xét