Giám sát hệ thống nhà máy 2026 – Thời gian phát hiện quyết định tổn thất

Trong nhà máy, khoảng thời gian không ai biết rằng máy chủ đã ngừng còn đắt hơn chính sự cố ngừng đó. Khi chúng tôi đến thăm các nhà máy Nhật Bản tại Thái Lan và trao đổi về sự cố, câu chuyện gần như luôn dồn về nguyên nhân. Thiết bị nào hỏng, cấu hình nào sai. Thế nhưng thứ thực sự quyết định tổn thất tại hiện trường không phải nguyên nhân, mà là khoảng thời gian từ lúc bất thường xảy ra cho đến lúc có người nhận ra. Bài viết này lấy một nhà máy gia công chi tiết kim loại ở tỉnh Ayutthaya làm trường hợp mô hình, đếm 14 sự cố trong một năm, và tính một cách trung thực xem việc rút thời gian phát hiện từ 2.4 giờ xuống 9 phút mang lại bao nhiêu THB. Xin nói trước kết luận, chỉ riêng hiệu quả của việc phát hiện sớm thì chưa thu hồi được chi phí giám sát. Chúng ta sẽ lần lượt xem lý do vẫn nên triển khai giám sát nằm ở đâu.

Trong nhà máy, tổn thất đến từ việc phát hiện muộn chứ không phải từ bản thân sự cố

Việc bàn về xử lý sự cố thường bắt đầu bằng truy tìm nguyên nhân. Ổ đĩa hỏng, bộ nguồn chết, bản cập nhật ghi đè lên cấu hình. Cuộc bàn luận đó có ý nghĩa, vì xác định được nguyên nhân thì mới lập được biện pháp phòng tái diễn. Nhưng với câu hỏi sự cố đó gây thiệt hại bao nhiêu tiền thì nguyên nhân hầu như không có câu trả lời nào.

Thứ quyết định độ lớn của tổn thất là khoảng thời gian hệ thống ngừng, và chính xác hơn là phần thời gian mà không ai hay biết. Thời gian dành cho công việc khôi phục được quy định bởi mức độ nặng nhẹ của nguyên nhân. Thay ổ đĩa mất vài giờ, hoàn nguyên cấu hình mất vài chục phút. Đây là chuyện kỹ thuật và không dễ rút ngắn đáng kể chỉ bằng nỗ lực. Ngược lại, thời gian cho đến khi nhận ra không phải chuyện kỹ thuật mà là chuyện cơ chế. Thay đổi cơ chế thì riêng phần này rút ngắn rất mạnh.

Điều thường thấy ở các nhà máy Nhật Bản tại Thái Lan là việc phát hiện sự cố phụ thuộc vào báo cáo của người dùng. Khi hệ thống quản lý sản xuất không phản hồi, nhân viên hiện trường trước tiên thử tải lại màn hình vài lần. Vẫn không được thì quay sang hỏi người bên cạnh xem máy của họ có chạy không. Sau khi vài người cùng xác nhận và biết chắc đây không phải lỗi máy của mình, sự việc mới đến được bộ phận hành chính. Cả chuỗi thao tác đó dễ dàng ngốn mất 1 đến 2 giờ.

Hơn nữa, độ trễ này còn kéo dài thêm vào ban đêm và ngày nghỉ. Máy chủ ngừng vào khung giờ không ai sử dụng sẽ nằm im như vậy cho đến giờ bắt đầu ca sáng hôm sau. Nếu ngừng vào lúc nửa đêm khi tác vụ xử lý theo lô đang chạy, sự việc sẽ lộ ra vào buổi sáng dưới dạng dữ liệu của hôm qua không có. Thứ bị mất trong trường hợp này không phải bản thân thời gian ngừng, mà là sự chậm trễ khi khởi động vì không thể phát lệnh sản xuất đầu ngày.

Trong các khảo sát với những doanh nghiệp quy mô lớn, tổn thất được báo cáo cho mỗi 1 giờ hệ thống ngừng là một con số rất lớn, và Cost of IT Downtime của OutageCost.com cũng dẫn kết quả khảo sát của ITIC và Uptime Institute theo hướng đó. Tuy nhiên, những con số ấy đến từ các tổ chức lớn chủ yếu ở Hoa Kỳ, nên không thể áp thẳng lên một nhà máy Nhật Bản quy mô vừa tại Thái Lan. Cấu trúc ngành và quy mô giao dịch chịu ảnh hưởng khi hệ thống ngừng đều khác nhau. Bài viết này chỉ tham chiếu các khảo sát đó như thông tin bối cảnh rằng ở những doanh nghiệp quy mô lớn có tồn tại kết quả khảo sát ở mức đó, và hoàn toàn không dùng chúng cho ước tính của trường hợp mô hình. Tổn thất của nhà máy mình phải được tính từ điều kiện của chính nhà máy mình.

Và thứ đầu tiên cần có để tính được chính là con số về thời gian cho đến khi phát hiện. Nhà máy không nắm con số này thì cũng chưa có dữ liệu để phán đoán có nên đầu tư vào giám sát hay không.

Giám sát hệ thống là gì – 3 loại gồm tình trạng sống, hiệu năng và nhật ký

Cụm từ giám sát hệ thống rất tiện trong hội thoại thường ngày, nhưng quá mơ hồ cho khâu thiết kế, bởi tùy vào việc bạn theo dõi cái gì mà loại bất thường có thể phát hiện sẽ khác nhau hoàn toàn. Trong thực tế chúng tôi chia thành 3 loại.

Loại thứ 1 là giám sát tình trạng sống. Chỉ xem thiết bị hoặc dịch vụ còn sống hay không. Gửi tín hiệu đến máy chủ theo chu kỳ cố định và xác nhận có phản hồi. Gọi màn hình web định kỳ và xác nhận có nhận được phản hồi bình thường. Đây là cơ chế đơn giản nhất và dễ triển khai nhất. Thứ phát hiện được chỉ là trạng thái ngừng hoàn toàn, nhưng sự cố đắt đỏ nhất trong thực tế nhà máy lại chính là ngừng hoàn toàn, nên xét về hiệu quả chi phí thì đây là mảng nên làm trước.

Loại thứ 2 là giám sát hiệu năng. Theo dõi trạng thái vẫn sống nhưng chậm. Tỷ lệ sử dụng CPU, bộ nhớ còn trống, dung lượng ổ đĩa còn trống, băng thông mạng, thời gian phản hồi của cơ sở dữ liệu. Đo liên tục các chỉ số này và báo khi giá trị lệch khỏi mức bình thường. Khác với giám sát tình trạng sống, loại này đòi hỏi một quyết định thiết kế về việc đặt ngưỡng ở đâu. Thiết kế sai thì sẽ rơi vào thất bại kinh điển được nói tới ở phần sau, đó là cảnh báo kêu quá nhiều đến mức không ai còn xem.

Loại thứ 3 là giám sát nhật ký. Lọc ra những mẫu nhất định từ các bản ghi mà thiết bị và phần mềm xuất ra. Xác thực thất bại lặp lại nhiều lần trong thời gian ngắn, lỗi đọc ghi ổ đĩa bắt đầu xuất hiện, tác vụ sao lưu kết thúc bất thường. Giám sát nhật ký là phương tiện duy nhất nắm bắt được trạng thái chưa ngừng nhưng đang trên đường ngừng. Đổi lại, việc quyết định lọc cái gì là khó nhất, và không thể cấu hình nếu không hiểu bên trong hệ thống đích.

Ba loại này khác nhau ở thời điểm có thể phát hiện. Giám sát nhật ký bắt được ở giai đoạn dấu hiệu báo trước, giám sát hiệu năng bắt ở giai đoạn suy giảm, còn giám sát tình trạng sống bắt ở giai đoạn đã ngừng. Lý tưởng là có đủ cả 3, nhưng thực tế bị ràng buộc bởi ngân sách và năng lực vận hành nên phải xếp thứ tự ưu tiên. Với nhà máy chưa có giám sát nào, bắt đầu từ giám sát tình trạng sống là công thức chuẩn, vì hiệu quả dễ thấy nhất và cấu hình nhẹ nhất.

Phạm vi đối tượng cũng cần được xác định. Chỉ theo dõi máy chủ là đủ, hay phải bao gồm cả thiết bị mạng. Trong nhà máy, sự cố phía mạng rất thường ảnh hưởng trực tiếp tới sản xuất, đặc biệt khi các điểm phát sóng không dây rớt thì việc nhập kết quả bằng máy đọc cầm tay sẽ dừng đồng loạt. Phân đoạn không dây có nhiều yếu tố gây mất ổn định hơn có dây, nên đưa giám sát vào ngay từ khâu thiết kế là cách làm thực tế. Về thiết kế mạng nhà máy, chúng tôi đã trình bày trong những điểm then chốt khi xây dựng mạng LAN không dây cho nhà máy, xin mời tham khảo cùng bài này.

Có điều cần quyết trước câu hỏi có thuê ngoài không – phân vai với dịch vụ thuê ngoài bộ phận IT

Khi nêu chuyện giám sát, câu hỏi đầu tiên thường là có thuê ngoài được không. Việc một cơ sở tại Thái Lan chỉ có 1 hoặc 2 người phụ trách hệ thống thông tin, đôi khi còn kiêm nhiệm, là hết sức bình thường, nên đó là phản ứng dễ hiểu.

Đằng sau phản ứng đó còn có khó khăn về tuyển dụng. Theo khảo sát của JETRO, 56.7% doanh nghiệp Nhật Bản tại Thái Lan trả lời rằng tình trạng thiếu nhân lực công nghệ thông tin như lập trình viên là rất nghiêm trọng hoặc khá nghiêm trọng, gần với mức 58.2% của toàn khu vực châu Á và châu Đại Dương. Nguyên nhân được nêu gồm dân số trong độ tuổi lao động giảm, sức cạnh tranh tuyển dụng yếu đi so với các tập đoàn Thái Lan và doanh nghiệp hạ tầng, và sự quan tâm dành cho doanh nghiệp Nhật Bản giảm sau khi tiếng Nhật bị tiếng Hàn vượt qua trong lựa chọn ngoại ngữ thứ hai của kỳ thi vào đại học. Nói ngắn gọn, phương án tăng người để canh hệ thống tới đêm vốn đã khó với tới ngay từ đầu.

Tuy vậy, đặt câu hỏi thuê ngoài lên trước thì câu chuyện thường tắc lại. Khi xin báo giá, nhà cung cấp bao giờ cũng hỏi ngược lại rằng sẽ giám sát những gì, điều kiện cảnh báo ra sao, và bên nào thực hiện xử lý ban đầu. Chúng tôi đã chứng kiến nhiều lần việc xem xét dừng hẳn đúng tại điểm đó vì không trả lời được. Có thuê ngoài hay không là câu hỏi chỉ trả lời được sau khi nội dung giám sát đã được xác định.

Thứ chưa được xác định không phải là chuyện thuê ngoài. Có 3 thứ chưa được xác định. Đo cái gì, tới mức nào thì coi là bất thường, và khi phát hiện rồi thì gửi cho ai bằng cách nào. Nếu 3 thứ này đã rõ thì dù tự làm hay giao ra ngoài đều cho kết quả như nhau. Ngược lại, nếu chưa rõ thì chọn đường nào cũng thất bại giống nhau.

Vì thế bài viết này không bàn trực tiếp chuyện có thuê ngoài hay không. Về việc đẩy 3 lớp gồm giám sát, bàn trợ giúp và bảo trì ra ngoài tới đâu và hiệu quả đầu tư ra sao, chúng tôi đã trình bày trong tách theo lớp để suy nghĩ về thuê ngoài bộ phận IT tại cơ sở Thái Lan. Bài này dừng ở bước trước đó, tức là thiết kế bản thân hoạt động giám sát.

Dù vậy, biết các dịch vụ giám sát bên ngoài được phân tầng thế nào vẫn hữu ích khi sắp xếp xem mình giữ lại phần nào. Lấy thị trường Nhật Bản làm mốc tham chiếu, bảng so sánh dịch vụ MSP của ASPIC giới thiệu cách chia thành tầng chỉ gửi cảnh báo, tầng tiêu chuẩn có kèm xử lý ban đầu, và tầng cao hơn bao gồm phân tích nguyên nhân và báo cáo cải tiến. Mức giá là của thị trường Nhật Bản nên không dùng làm giá thị trường Thái Lan được, nhưng chính cách phân tầng đó lại là ngôn ngữ chung hữu ích khi quyết định phân vai cho mình. Chỉ nhận cảnh báo rồi tự xử lý, hay giao luôn cả xử lý ban đầu. Ranh giới này tự nó rõ ra khi thiết kế giám sát đã hoàn tất.

Lớp thứ 4 mà các nhà máy tại Thái Lan hay bỏ sót – chất lượng điện

Phần trước đã chia giám sát thành 3 loại, nhưng với nhà máy tại Thái Lan còn thêm 1 đối tượng nữa cần được xử lý như một lớp độc lập. Đó là chất lượng điện.

Lý do phải tách riêng là vì giám sát công nghệ thông tin thuần túy không phát hiện được nó. Giám sát tình trạng sống chỉ phản ứng sau khi thiết bị đã đổ. Trong lúc điện áp phía nguồn đang tụt, máy chủ vẫn còn chạy nên giám sát tình trạng sống không báo gì cả. Giám sát hiệu năng cũng vậy, vì tỷ lệ sử dụng CPU và dung lượng ổ đĩa còn trống không liên quan gì tới điện áp. Giám sát nhật ký thì cuối cùng cũng để lại bản ghi rằng máy đã tắt do lỗi nguồn, nhưng đó là bản ghi sau khi sự việc đã xảy ra.

Tình hình điện của Thái Lan có đặc điểm khác Nhật Bản. Theo phần giải thích của Biz Info Log, tại Thái Lan hiện tượng sụt áp tức thời phổ biến hơn mất điện hoàn toàn, và xảy ra nhiều lần mỗi năm ngay cả ở khu vực đô thị Bangkok. Vì sụt áp tức thời hồi phục trong vài giây nên đèn chiếu sáng chỉ nhấp nháy và thiết bị sản xuất vẫn chạy tiếp. Nhưng máy chủ và bộ chuyển mạch mạng đôi khi không chịu nổi vài giây đó và khởi động lại.

Rắc rối hơn nữa là bản thân sự kiện sụt áp hầu như không để lại dấu vết trong hồ sơ. Không ai trong nhà máy nhận thức rằng đã có mất điện, nên máy chủ khởi động lại bị ghi nhận là sự cố không rõ nguyên nhân. Chuyện cũ lặp lại mà không có lời giải thích, và mỗi lần như vậy câu chuyện lại thành máy chủ dở chứng nữa rồi. Trên thực tế đó không phải vấn đề của thiết bị mà là vấn đề phía nguồn điện.

Chính vì thế cần đưa việc giám sát UPS, tức bộ lưu điện, và phía nguồn vào như một lớp tách khỏi giám sát công nghệ thông tin. Cụ thể, thứ cần theo dõi là số lần UPS phát hiện bất thường của nguồn đầu vào, thời điểm xảy ra chuyển sang chạy pin, dung lượng còn lại và độ lành mạnh của pin, cùng trạng thái đầu ra. Bản thân UPS đã có sẵn các thông tin này, chỉ cần gắn thẻ quản lý mạng là lấy ra được. UPS không gắn thẻ thì có thông tin nhưng không đưa ra ngoài được. Chỉ riêng việc kiểm tra điểm này thôi cũng đã đáng làm.

Chừng nào chất lượng điện chưa được giữ như lớp thứ 4 thì cấu trúc chỉ biết sau khi đã đổ sẽ không thay đổi. Bởi dù giám sát phía công nghệ thông tin có tinh vi đến đâu, các sự cố có nguyên nhân nằm ở phía nguồn vẫn luôn bị phát hiện sau khi đã xảy ra.

Trường hợp mô hình | Đếm sự cố tại nhà máy chi tiết kim loại ở tỉnh Ayutthaya

Từ đây chúng ta sẽ xem bằng những con số cụ thể. Những gì trình bày sau đây là trường hợp mô hình dựa trên ước tính riêng của chúng tôi, không phải số liệu của một doanh nghiệp có thật. Xin hãy nhìn vào quy trình rằng thời gian đang mất ở đâu và bao nhiêu, rồi được quy ra tiền như thế nào, hơn là nhìn vào bản thân số tiền.

Giả định như sau. Một nhà máy gia công chi tiết kim loại vốn Nhật Bản tại tỉnh Ayutthaya, Thái Lan, làm linh kiện ô tô, có 210 nhân viên. Môi trường công nghệ thông tin gồm 1 máy chủ đặt tại chỗ chạy hệ thống quản lý sản xuất, 1 máy chủ tệp, và mạng nội bộ nhà máy với 8 bộ chuyển mạch cùng 12 điểm phát sóng không dây. Hệ thống quản lý sản xuất có 48 người dùng thường xuyên, dùng để kiểm tra thông tin đơn hàng, phát lệnh sản xuất, nhập kết quả và lập lệnh giao hàng.

Nhà máy chưa triển khai giám sát. Sự cố được biết đến khi người dùng liên hệ báo rằng không mở được hệ thống. Với các nhà máy gia công vốn Nhật Bản tại Thái Lan thì đây là tình trạng hết sức tiêu chuẩn.

Bảng dưới đây đếm các sự cố xảy ra tại nhà máy này trong 1 năm, phân theo nguyên nhân.

Tổng cộng 14 vụ mỗi năm, tức hơn 1 vụ mỗi tháng. Nhìn con số này, có người thấy nhiều hơn mình tưởng, có người thấy cũng bình thường thôi. Lý do cảm nhận khác nhau là vì về căn bản không ai đếm cả. Ở nhà máy không đếm, chỉ những sự cố lớn còn nhớ được mới được tính là một vụ, còn những lần ngừng nhỏ khôi phục trong 30 phút thì không vào danh sách.

Điều đáng chú ý trong bảng này là cơ cấu nguyên nhân. Sự cố do phần mềm và thiết bị là 6 vụ, trong khi sự cố do chất lượng điện lên tới 8 vụ. Tỷ trọng của nguyên nhân điện trong tổng số 14 vụ là 8 chia cho 14, khoảng 57%. Dù hơn một nửa có gốc rễ ở phía nguồn điện, khi bàn về giám sát thì điện gần như không bao giờ được nhắc tới.

Độ lệch theo mùa cũng rất rõ. Trong tổng số 14 vụ, mùa mưa có 9 vụ và mùa khô có 5 vụ. Độ lệch này đến từ đâu sẽ thấy khi tách theo nguyên nhân. Sáu vụ do phần mềm và thiết bị chia thành 3 vụ mùa mưa và 3 vụ mùa khô, đúng 50% mỗi bên, hoàn toàn không có tính mùa vụ. Còn 8 vụ do chất lượng điện chia thành 6 vụ mùa mưa và 2 vụ mùa khô, tỷ lệ mùa mưa là 75%. Như vậy độ lệch theo mùa gần như hoàn toàn đến từ phía nguồn điện.

Vì sao sự cố dồn vào mùa mưa – sụt áp tức thời và lão hóa pin UPS

Lý do sự cố về điện dồn vào mùa mưa nằm ở chính thời tiết. Theo chuyên mục của PC Support Thailand do Thai Jiyu Land giới thiệu, tại Thái Lan trong mùa mưa từ tháng 5 đến tháng 10, mưa rào và giông sét gây mất điện cùng sụt áp tức thời rất thường xuyên, làm tăng rủi ro hỏng hóc cho máy chủ và thiết bị mạng. Thiệt hại do sét đánh trực tiếp ít gặp hơn nhiều so với các dao động điện áp tức thời phát sinh trên lưới truyền tải.

Nhìn từ phía nhà máy, hiện tượng này biểu hiện dưới dạng rất khó hiểu. Sự việc máy chủ khởi động lại vào buổi chiều một ngày mưa lớn thì còn ghi nhận được, nhưng không có bất kỳ bản ghi nào về việc điện áp lúc đó ra sao. Hôm sau người phụ trách báo cáo rằng hôm qua máy chủ bị đổ, và cấp quản lý chỉ đạo hãy tìm nguyên nhân. Nhưng không có cách nào tìm cả. Cái không được ghi lại thì không thể điều tra.

Điểm quan trọng ở đây là UPS. UPS tiếp tục cấp điện trong khoảng sụt áp nên nếu hoạt động đúng thì thiết bị sẽ không đổ. Có điều cụm từ nếu hoạt động đúng đi kèm điều kiện. Pin bên trong phải chưa lão hóa, và dung lượng phải đủ so với tải thực tế.

Cũng chuyên mục đó khuyến nghị lắp UPS đồng thời chỉ ra rằng điều kiện nhiệt độ phòng ở Thái Lan làm pin lão hóa nhanh. Nói chung, trong môi trường nhiệt độ phòng quanh mức 30 độ C, pin trong UPS có xu hướng lão hóa trong khoảng 1 năm, nên việc kiểm tra và xác nhận thay pin 1 lần mỗi năm được xem là mốc tham chiếu. Nếu giữ cảm nhận kiểu Nhật Bản rằng pin dùng được vài năm thì sẽ gặp cảnh có UPS mà thiết bị vẫn đổ khi sụt áp ập đến.

Và pin lão hóa thì lão hóa một cách lặng lẽ. Đèn trên thân UPS vẫn sáng và điện vẫn thông. Việc thiếu dung lượng chỉ lộ ra đúng lúc thiết bị thực sự chuyển sang chạy pin. Nói cách khác, việc có UPS hoàn toàn không bảo đảm khả năng chịu được sụt áp. UPS chỉ bắt đầu phát huy vai trò như một khoản đầu tư khi độ lành mạnh của pin được đưa vào danh sách giám sát.

Nhà máy trong trường hợp mô hình cũng có lắp UPS. Nhiều năm trôi qua với nhận thức rằng đã lắp rồi nên không sao, trong khi hiện tượng máy chủ đổ vì sụt áp mùa mưa vẫn tiếp diễn. Đó là bối cảnh của 8 vụ có nguyên nhân từ điện. Vấn đề không phải là chưa mua thiết bị, mà là chưa từng theo dõi tình trạng của thiết bị đã mua.

Vì sao phải mất tới 2.4 giờ mới phát hiện ra

Tại nhà máy này, thời gian trung bình từ khi sự cố phát sinh đến khi bộ phận hành chính nhận biết là 2.4 giờ. Phân tách xem vì sao lại lâu đến vậy sẽ thấy vài giai đoạn.

Giai đoạn đầu tiên là thời gian để người dùng kết luận rằng đây là bất thường. Khi màn hình hệ thống quản lý sản xuất không mở được, người dùng trước hết nghi ngờ thao tác của mình hoặc máy của mình. Họ thử khởi động lại, thử mở bằng trình duyệt khác, và khi vẫn không được thì đứng dậy hỏi người bên cạnh. Chỉ riêng giai đoạn này đã trôi qua vài chục phút. Đặc biệt với người dùng không mở hệ thống thường xuyên, họ chỉ nhận ra khi định mở lần kế tiếp, nên độ lệch so với thời điểm sự cố thực tế còn lớn hơn nữa.

Giai đoạn tiếp theo là đường báo cáo. Ở phần lớn nhà máy, trục trặc hệ thống được báo cho tổ trưởng hiện trường trước, rồi tổ trưởng mới liên hệ bộ phận hành chính. Nếu tổ trưởng đang họp thì chậm thêm bấy nhiêu. Nếu kênh liên lạc là ứng dụng trò chuyện thì tương đối nhanh, còn nếu dựa vào truyền miệng hoặc điện thoại thì sẽ phát sinh chờ đợi khi đối phương vắng mặt.

Giai đoạn thứ ba là khung giờ. 48 người dùng không cùng làm việc trong một khung giờ. Nếu hệ thống ngừng vào giờ nghỉ trưa thì phải hết giờ nghỉ mới có người nhận ra. Nếu máy chủ tệp ngừng trong ca đêm thì đến sáng hôm sau mới có người đụng tới. Chính những sự cố phát sinh trong các khung giờ không ai sử dụng đã kéo giá trị trung bình lên cao. Con số trung bình 2.4 giờ là kết quả trộn lẫn giữa những lần phát hiện trong 10 phút và những lần không ai hay biết suốt 8 giờ.

Và giai đoạn thứ tư, cũng là giai đoạn hay bị bỏ sót nhất, là trạng thái đã biết nhưng không báo. Đó là trường hợp nhân viên hiện trường quyết định rằng đã không dùng được hệ thống thì cứ ghi ra giấy rồi nhập sau, và tiếp tục làm việc. Trong khung nhìn của họ vấn đề đã được né tránh xong nên không có động lực báo cáo. Hiện trường càng giỏi né tránh kiểu này thì sự cố càng ít nổi lên. Không nổi lên thì không có biện pháp, và chuyện cũ lại lặp lại.

Nhìn cả 4 giai đoạn sẽ thấy một điểm chung. Tất cả đều phụ thuộc vào phán đoán của con người và liên lạc của con người. Đào tạo con người để nhanh hơn thì về lý thuyết vẫn làm được, nhưng bắt con người phát hiện việc máy chủ ngừng trong ca đêm khi không ai dùng thì về nguyên tắc là bất khả thi. Đây chính là lý do cốt lõi khiến cần đến cơ chế mang tên giám sát.

Khi lắp giám sát thì thời gian phát hiện rút ngắn tới đâu

Khi triển khai giám sát tình trạng sống cùng cảnh báo theo ngưỡng, thời gian cho đến khi phát hiện rút xuống trung bình 9 phút, quy ra là 0.15 giờ. Cấu thành của 9 phút này cũng rất rõ ràng.

Hệ thống giám sát xác nhận phản hồi từ đối tượng theo chu kỳ cố định. Rút ngắn chu kỳ này thì phát hiện nhanh hơn, nhưng tải lên thiết bị được giám sát và lưu lượng truyền thông đều tăng. Trong thực tế, chu kỳ kiểm tra thường được đặt ở mức vài phút một lần, và thay vì cảnh báo ngay khi thất bại 1 lần, hệ thống được cấu hình để coi là bất thường sau vài lần thất bại liên tiếp. Cảnh báo ngay từ lần đầu sẽ khiến dao động nhất thời của đường truyền gây báo nhầm liên tục. Tích của chu kỳ kiểm tra và số lần thất bại liên tiếp chính là phần chủ yếu của độ trễ phát hiện.

Cộng thêm vào đó là thời gian gửi cảnh báo, tức vài chục giây từ lúc kết luận bất thường đến lúc thông báo tới được email hoặc ứng dụng trò chuyện. Cộng lại, con số dừng ở mức trung bình 9 phút.

Thời gian rút ngắn cho mỗi vụ là 2.4 giờ trừ 0.15 giờ, bằng 2.25 giờ. Quy ra tỷ lệ, 2.25 chia cho 2.4 là khoảng 94%. Nghĩa là hơn chín phần mười thời gian cho đến khi nhận ra đã biến mất. Mức rút ngắn lớn như vậy cũng chính là hình phản chiếu của việc trạng thái ban đầu phụ thuộc vào báo cáo người dùng. Nhà máy đã có sẵn một mức giám sát nào đó thì làm cùng biện pháp cũng không đạt hiệu quả tới mức này.

Điều cần lưu ý là thứ mà giám sát rút ngắn chỉ là thời gian cho đến khi phát hiện. Thời gian từ lúc phát hiện đến lúc khôi phục xong thì giám sát không rút được. Ổ đĩa đã hỏng thì thời gian thay vẫn vậy, và nếu hoàn nguyên cấu hình mất 30 phút thì 30 phút đó vẫn nguyên. Đôi khi người ta giải thích rằng lắp giám sát vào thì tổng thời gian khôi phục sẽ ngắn lại, nhưng nói chính xác thì chỉ phần cho đến khi phát hiện là ngắn lại, và nếu để sự phân biệt này mờ đi thì về sau dự án sẽ bị đánh giá là không có hiệu quả.

Ngoài ra, nếu chưa xác định ai nhận cảnh báo phát hiện được vào ban đêm và ngày nghỉ thì dù phát hiện nhanh hơn, việc xử lý cũng chưa bắt đầu. Nếu thông báo reo lúc 2 giờ sáng mà không ai xem cho tới sáng thì thời gian phát hiện thực chất không khác gì phụ thuộc báo cáo người dùng. Điểm này thuộc về trục thứ 3 của thiết kế giám sát, tức đường thông báo, sẽ được nói ở phần sau.

Định giá 1 giờ rút ngắn thời gian phát hiện như thế nào

Để quy giá trị của việc phát hiện nhanh hơn ra tiền, cần xác định 1 giờ hệ thống ngừng mà không ai biết gây thiệt hại bao nhiêu. Phần này khác nhau rất nhiều giữa các nhà máy nên chúng tôi nêu rõ điều kiện của trường hợp mô hình rồi cộng dồn từng khoản. Xin nhắc lại đây là ước tính riêng của chúng tôi.

Trước hết, dù hệ thống quản lý sản xuất ngừng thì công việc hiện trường cũng không dừng toàn bộ ngay lập tức. Tại nhà máy này, những công đoạn đã có lệnh sản xuất trong tay vẫn gia công tiếp được. Việc ghi kết quả cũng có thể thay bằng giấy. Cảm nhận của hiện trường là chống đỡ được khoảng 30 phút bằng cách vận hành trên giấy.

Vấn đề bắt đầu sau đó. Quá 30 phút thì không phát được lệnh xếp hàng cho xe tải giao hàng. Vì lệnh giao hàng phải xuất từ hệ thống nên khi hệ thống ngừng, không thể xác nhận phải xếp sản phẩm nào và bao nhiêu thùng. Kết quả là xe tải đã tới phải chờ trong khuôn viên, và theo hợp đồng với công ty vận tải, thời gian chờ này phát sinh chi phí thực.

Khoản thứ hai là thời gian của nhân sự tham gia xử lý. Khi có sự cố, người phụ trách hệ thống thông tin và người phụ trách quản lý sản xuất phải rời công việc chính để xử lý. Nếu xảy ra ngoài giờ làm việc thì đó trực tiếp trở thành làm thêm giờ.

Bảng dưới đây cộng dồn 2 khoản này theo đơn giá và số lượng.

Chi phí chờ của xe tải giao hàng là 800 THB mỗi giờ cho mỗi xe, số xe chịu ảnh hưởng trung bình là 1.2 xe, nhân lên được 960 THB mỗi giờ. Nhân sự xử lý là 2 người với đơn giá giờ 350 THB, được 700 THB mỗi giờ. Cộng lại, 1 giờ hệ thống ngừng mà không ai biết có giá trị 1,660 THB.

Cách cộng dồn này có một thứ cố ý không đưa vào, đó là tổn thất cơ hội do bản thân sản xuất ngừng. Như đã nói, nhà máy này duy trì được sản xuất bằng giấy trong một khoảng thời gian nhất định, nên những lần ngừng ngắn không ảnh hưởng tới sản lượng. Ngừng dài thì đương nhiên có ảnh hưởng, nhưng khi bắt đầu giả định xác suất và quy mô của nó thì toàn bộ ước tính sẽ trở thành sự chồng chất của các giả định. Ở đây chúng tôi chỉ cộng những chi phí chắc chắn phát sinh. Xin hiểu đây là một con số khá thận trọng.

Ước tính riêng | Đặt hiệu quả năm của việc phát hiện sớm cạnh chi phí giám sát

Nguyên liệu đã đủ, chúng ta tính hiệu quả trong một năm.

Số sự cố mỗi năm là 14 vụ, thời gian phát hiện rút ngắn mỗi vụ là 2.25 giờ, nên tổng thời gian rút ngắn trong một năm là 14 nhân 2.25, bằng 31.5 giờ. Nhân 31.5 giờ này với chi phí 1,660 THB cho mỗi giờ không phát hiện, ta được khoản tiết giảm mỗi năm là 52,290 THB.

Ở chiều ngược lại là chi phí triển khai giám sát. Chi phí ban đầu, bao gồm dựng máy chủ giám sát hoặc dịch vụ đám mây, cài tác tử lên từng thiết bị, cấu hình thẻ quản lý mạng của UPS, dựng bảng điều khiển và thiết lập đường thông báo, là 180,000 THB. Phí dịch vụ giám sát hằng tháng, gồm giám sát tình trạng sống và gửi cảnh báo, là 28,000 THB mỗi tháng, tính theo năm là 28,000 nhân 12, bằng 336,000 THB.

Đặt hai bên cạnh nhau ta có bảng sau.

Lấy hiệu quả năm 52,290 THB chia cho phí dịch vụ năm 336,000 THB được 15.6%. Chưa kịp tính tới chi phí ban đầu 180,000 THB thì riêng phí hằng tháng đã không được bù đắp.

Chúng tôi cố ý trình bày kết quả này đúng như nó vốn có. Muốn làm con số đẹp hơn thì có nhiều cách, chẳng hạn nâng đơn giá của chi phí không phát hiện, đưa tổn thất cơ hội do sản xuất ngừng vào, hoặc ước lượng số vụ sự cố cao hơn. Nhưng làm vậy thì ước tính sẽ thành công cụ thuyết phục chứ không còn là dữ liệu để quyết định.

Đọc một cách trung thực, ước tính này chỉ nói một điều. Chỉ quy ra tiền hiệu quả của việc rút ngắn thời gian phát hiện thì chưa thu hồi được chi phí giám sát. Mọi quyết định về việc có triển khai giám sát hay không đều phải xây trên sự thật đó.

Chỉ riêng phát hiện sớm thì chưa hoàn vốn – lý do không quy ra tiền hiệu quả còn lại

Vậy có phải giám sát không đáng đầu tư không. Câu trả lời là không phải, vì vẫn còn một hiệu quả chúng tôi chưa quy ra tiền. Đó là hiệu quả ngăn sự việc leo thang.

Những bất thường nhỏ, nếu bỏ mặc, sẽ lớn lên thành những lần ngừng lớn. Trạng thái dung lượng ổ đĩa trống giảm dần tự nó không làm gì ngừng cả, nhưng đúng khoảnh khắc về không thì cơ sở dữ liệu dừng. Trạng thái RAID hỏng 1 ổ vẫn hoạt động tiếp, chỉ là mất tính dư thừa, nhưng ổ thứ 2 hỏng thì mất trắng. Pin UPS lão hóa cũng vậy, không có gì xảy ra cho tới lần sụt áp kế tiếp. Còn tác vụ sao lưu thất bại liên tục thì nặng hơn nữa, vì không ai thấy bất tiện cho tới khi có sự cố, và ngay khoảnh khắc có sự cố thì đã không cứu vãn được.

Giám sát hiệu năng và giám sát nhật ký nắm bắt đúng những trạng thái chưa ngừng nhưng đang đi về hướng sẽ ngừng này. Nắm được rồi ra tay thì bản thân lần ngừng lớn sẽ không xảy ra. Và tổn thất của một sự cố không xảy ra thì đương nhiên không được ghi ở đâu cả, vì nó đã không xảy ra.

Nếu cố quy hiệu quả đó ra tiền thì luôn cần đến giả định về xác suất. Đáng lẽ ổ đĩa đầy bao nhiêu lần một năm. Xác suất ổ thứ 2 của RAID hỏng là bao nhiêu. Bao nhiêu năm mới xảy ra một tình huống thực sự cần đến bản sao lưu. Không con số nào đặt được với căn cứ vững chắc. Đặt vào thì bậc của con số sẽ thay đổi, nhưng cái bậc mới ấy không có ý nghĩa gì.

Vì vậy bài viết này không quy hiệu quả ngăn leo thang ra tiền. Điều đó không có nghĩa hiệu quả này nhỏ, mà có nghĩa là không thể ước tính một cách trung thực. Quy ra tiền cái không thể quy ra tiền sẽ khiến toàn bộ lập luận đầu tư mất uy tín.

Về mặt thực hành, chúng tôi khuyến nghị trình bày tách làm 2 phần. Phần thứ nhất là hiệu quả của việc rút ngắn thời gian phát hiện, có thể thể hiện bằng tiền. Trong trường hợp mô hình là 52,290 THB mỗi năm. Phần thứ hai không quy ra tiền, mà liệt kê cụ thể những sự kiện muốn phòng tránh. Trạng thái cơ sở dữ liệu ngừng khiến không nhập được kết quả sản xuất của cả một ngày. Trạng thái máy chủ hỏng trong khi không ai biết rằng sao lưu đã không chạy. Trạng thái sụt áp mùa mưa mà UPS không chống đỡ nổi khiến hệ thống quản lý sản xuất đổ. Trong quy trình phê duyệt nội bộ, chính bản liệt kê này mới thực sự có sức nặng, vì việc bày ra cụ thể những chuyện xảy ra thì rất phiền có ý nghĩa với người ra quyết định hơn là con số 15.6%.

Nhân đây, việc giám sát xem sao lưu có đang chạy hay không là hạng mục ưu tiên cao trong thiết kế giám sát. Về thiết kế sao lưu, chúng tôi đã trình bày chi tiết trong cơ chế sao lưu và tư duy khôi phục cho hệ thống nghiệp vụ, xin mời xem cùng lúc với việc rà soát danh sách đối tượng giám sát.

3 trục thiết kế giám sát – đo cái gì, tới đâu là bất thường, gửi cho ai

Xin chuyển toàn bộ nội dung trên sang ngôn ngữ của thiết kế. Có 3 thứ phải quyết trong thiết kế giám sát.

Trục thứ 1 là đo cái gì. Hãy lập danh sách đối tượng. Máy chủ, thiết bị mạng, điểm phát sóng không dây, UPS, và các dịch vụ đang chạy trên từng máy chủ. Cái bẫy dễ mắc ở đây là hài lòng với danh sách thiết bị. Máy chủ còn sống nhưng dịch vụ của hệ thống quản lý sản xuất chạy trên đó đã dừng thì với người dùng cũng không khác gì hệ thống đã ngừng. Hãy định nghĩa đối tượng đo theo đơn vị chức năng mà người dùng thực sự sử dụng, chứ không phải theo đơn vị thiết bị. Với định nghĩa kiểu màn hình đăng nhập của hệ thống quản lý sản xuất phản hồi bình thường thì hỏng ở bất kỳ đâu trên đường đi cũng phát hiện được.

Trục thứ 2 là tới mức nào thì coi là bất thường. Đây là thiết kế ngưỡng. Với giám sát tình trạng sống là bao nhiêu lần không phản hồi liên tiếp thì coi là bất thường. Với giám sát hiệu năng là tỷ lệ sử dụng CPU vượt mức cao trong bao nhiêu phút thì coi là bất thường, hoặc dung lượng ổ đĩa trống xuống dưới mức nào thì coi là bất thường. Thiết kế này không quyết được ngay sau khi lắp giám sát, vì phải đo giá trị trong trạng thái bình thường suốt một khoảng thời gian và nắm được độ dao động của nó thì mới kẻ được đường có ý nghĩa. Cách làm thực tế là đặt lỏng trong giai đoạn đầu rồi siết lại khi dữ liệu đã đủ.

Trục thứ 3 là sau khi phát hiện thì gửi đi đâu. Đây là thiết kế đường thông báo, phần bị xem nhẹ nhất và cũng thất bại nhiều nhất. Những thứ phải quyết là người nhận trong giờ làm việc ngày thường, người nhận vào ban đêm và ngày nghỉ, và người nhận thứ cấp khi không ai phản hồi. Thêm vào đó là phân loại theo mức độ quan trọng. Gửi mọi cảnh báo cho tất cả mọi người thì những thông báo quan trọng sẽ bị chìm. Việc hệ thống quản lý sản xuất ngừng thì phải làm điện thoại reo ngay lập tức, còn cảnh báo về dung lượng ổ đĩa trống thì để tới ngày làm việc kế tiếp cũng được.

Trong 3 trục này, thiếu bất kỳ trục nào thì giám sát cũng không hoạt động. Triển khai mà không quyết đối tượng thì sẽ có thứ bị bỏ sót. Triển khai mà không quyết ngưỡng thì cảnh báo sẽ reo quá nhiều. Triển khai mà không quyết đường thông báo thì phát hiện rồi cũng không ai động đậy. Và cả 3 điều này đều quyết được độc lập với việc có thuê ngoài dịch vụ giám sát hay không. Câu ở đầu bài rằng có điều cần quyết trước câu hỏi có thuê ngoài không chính là mang nghĩa này.

Về trình tự, hãy bắt đầu từ trục thứ 1. Đối tượng chưa rõ thì ngưỡng cũng chưa rõ, và ngưỡng chưa rõ thì mức độ quan trọng của thông báo cũng chưa rõ. Ngược lại, chỉ cần đối tượng đã rõ thì phần còn lại chỉ là công việc điền dần theo từng đối tượng.

Những kiểu thất bại điển hình khi thiết kế ngưỡng

Thiết kế ngưỡng là điểm rẽ lớn nhất khiến một dự án giám sát thất bại về mặt thực chất. Xin nêu những thất bại thường gặp.

Đặt ngưỡng quá chặt ngay từ đầu. Nếu ngay ngày đầu triển khai đã đặt cấu hình cảnh báo khi tỷ lệ sử dụng CPU vượt một mức cao thì cảnh báo sẽ reo mỗi đêm vào khung giờ tác vụ theo lô chạy. Khi tình trạng cảnh báo reo dù đó là hoạt động bình thường kéo dài, người phụ trách sẽ bắt đầu phớt lờ thông báo chỉ sau vài ngày, và khi phớt lờ thành thói quen thì bất thường thật sự đến cũng không ai nhận ra. Đã lắp giám sát mà không phát hiện được chính là trạng thái tệ nhất.

Thỏa hiệp bằng ngưỡng quá lỏng. Đây là phản ứng ngược lại của điều trên, tức nới ngưỡng cho tới khi cảnh báo không còn reo nữa. Đặt thông báo khi dung lượng ổ đĩa trống còn dưới 1% thì đúng là yên tĩnh thật, nhưng lúc thông báo tới thì đã không còn thời gian xử lý. Mục đích của ngưỡng là báo trong lúc còn xử lý được, chứ không phải báo rằng đã tới giới hạn.

Quyết ngưỡng mà không thu thập dữ liệu ở trạng thái bình thường. Đây là kiểu lấy nguyên các giá trị khuyến nghị chung để dùng. Hình dạng phụ tải khác nhau ở từng nhà máy. Có nhà máy tải cao suốt ban ngày, có nhà máy tác vụ theo lô ban đêm mới nặng nhất. Đường kẻ mà không biết trạng thái bình thường của chính mình là đường kẻ không có căn cứ. Hãy dành một khoảng thời gian sau khi triển khai cho việc thu thập dữ liệu, rồi mới chốt ngưỡng sau khi đã thấy biên độ dao động thực tế.

Không phân tách mức độ quan trọng của cảnh báo. Khi mọi thông báo đều tới bằng cùng một đường và cùng một định dạng thì bên nhận không thể sàng lọc. Thứ cần xử lý ngay, thứ chỉ cần kiểm tra trong ngày, và thứ chỉ cần xem gộp theo tuần. Chỉ cần chia thành khoảng 3 cấp như vậy thì hiệu lực thực tế của thông báo đã thay đổi rất nhiều.

Không rà soát lại ngưỡng đã đặt. Khi thiết bị tăng, người dùng tăng và lượng dữ liệu tăng thì giá trị ở trạng thái bình thường cũng dịch chuyển. Cứ dùng mãi ngưỡng của lúc triển khai thì vài năm sau sẽ không còn khớp với thực tế. Hãy dành thời gian khoảng 1 lần mỗi năm để xem các giá trị đo được gần đây và rà soát ngưỡng.

Điểm chung của những thất bại này là coi ngưỡng như một giá trị cấu hình kỹ thuật. Thực tế, ngưỡng là quy tắc vận hành quyết định ai sẽ hành động vào lúc nào. Đặt ngưỡng chặt ở nơi không có lực lượng ứng phó thì chỉ khiến cảnh báo chất đống. Hãy đặt ngưỡng phù hợp với số người có thể ứng phó và khung giờ họ có thể ứng phó.

Nhật ký giám sát và PDPA – thời hạn lưu trữ và quyền truy cập

Khi triển khai giám sát, sản phẩm phụ là nhật ký tích lũy lại. Ai đăng nhập lúc nào, thiết bị nào truy cập hệ thống nào, thao tác nào phát sinh lỗi. Những dữ liệu này hữu ích cho xử lý sự cố, nhưng cần thận trọng khi xử lý.

Luật Bảo vệ Dữ liệu Cá nhân của Thái Lan, tức PDPA, có hiệu lực đầy đủ từ ngày 1 tháng 6 năm 2022. Theo phần giải thích của KPMG, các đơn vị thuộc phạm vi điều chỉnh có nghĩa vụ lập hồ sơ về hoạt động xử lý dữ liệu cá nhân, và trong trường hợp xử lý có rủi ro cao còn có nghĩa vụ bổ nhiệm cán bộ bảo vệ dữ liệu, tức DPO. Việc xử lý dữ liệu liên quan đến theo dõi hành vi của chủ thể dữ liệu cũng được xem là có thể nằm trong phạm vi điều chỉnh.

Điều cần tránh hiểu nhầm là điều này không có nghĩa nhật ký giám sát nhất thiết là dữ liệu cá nhân. Thời gian phản hồi của máy chủ và tỷ lệ sử dụng CPU không gắn với cá nhân nào. Ngược lại, nhật ký truy cập có chứa mã người dùng thì có khả năng gắn với thông tin định danh cá nhân. Có thuộc phạm vi hay không tùy vào nội dung nhật ký, và không có câu trả lời chung cho mọi trường hợp. Việc phán đoán thực tế nên được thực hiện bằng cách liệt kê các trường nhật ký mà công ty đang thu thập rồi hỏi ý kiến chuyên gia.

Mức chế tài cũng không hề nhẹ. Phần giải thích của One Asia Lawyers cho thấy vi phạm có thể bị phạt hành chính tối đa 5,000,000 THB và phạt hình sự tối đa 1,000,000 THB. Việc triển khai giám sát thường tiến hành theo thuận tiện của bộ phận công nghệ thông tin, nhưng những người liên quan cần chia sẻ nhận thức rằng xử lý nhật ký cũng là một vấn đề pháp lý.

Có 3 điều tối thiểu nên quyết trong thực hành. Điều thứ 1 là thời hạn lưu trữ. Hãy xác định lưu để làm gì, đặt khoảng thời gian cần thiết cho mục đích đó, và xóa những gì đã quá hạn. Đặt kiểu lưu vô thời hạn cho chắc là cấu hình nguy hiểm nhất, theo nghĩa mục đích chưa được định nghĩa. Điều thứ 2 là quyền truy cập. Hãy nêu rõ ai được truy cập bảng điều khiển giám sát, và giới hạn phạm vi người được xem đối với những màn hình có chứa thông tin định danh cá nhân. Điều thứ 3 là rà soát các trường thu thập. Hãy kiểm tra cả khi triển khai lẫn khi rà soát định kỳ xem có đang thu thập những trường không cần cho xử lý sự cố hay không. Cái không thu thập thì cũng không phải quản lý.

Quyết 3 điều này ngay ở khâu thiết kế giám sát thì về sau sẽ không phát sinh việc thêm. Ngược lại, chạy hệ thống rồi mới đi sắp xếp cách xử lý nhật ký thì sẽ có thêm một vấn đề phiền phức nữa, đó là xử lý dữ liệu đã tích lũy.

Cách triển khai | 4 bước

Cuối cùng, xin sắp xếp lại các bước triển khai giám sát trên thực tế.

Bước 1 là kiểm kê đối tượng. Hãy lập danh sách toàn bộ máy chủ, thiết bị mạng, điểm phát sóng không dây và UPS trong nhà máy. Khi thực sự bắt tay làm, rất nhiều nhà máy phát hiện ra những thiết bị mà không ai biết là có tồn tại. Bộ chuyển mạch được thêm vào lúc mở rộng, máy chủ được lắp từ dự án trước còn để lại, hoặc điểm phát sóng không dây do người phụ trách tự lắp. Trước khi quyết giám sát cái gì, hãy xác định rõ có những gì đã. Đầu tư thời gian cho bước này là hoàn toàn xứng đáng.

Bước 2 là định nghĩa theo đơn vị chức năng nhìn từ phía người dùng. Khi đã có danh sách thiết bị, hãy dịch nó sang góc nhìn của người dùng. Hệ thống quản lý sản xuất dùng được, thư mục chia sẻ trên máy chủ tệp mở được, sóng không dây kết nối được. Hãy định nghĩa bằng câu chữ rằng bình thường nghĩa là gì theo đơn vị này. Nếu tiến sang cấu hình giám sát khi định nghĩa còn mơ hồ thì sẽ không phát hiện được trạng thái thiết bị xanh hết mà người dùng vẫn không làm việc được.

Bước 3 là triển khai giám sát tình trạng sống và giám sát nguồn điện. Tới đây mới lần đầu chạm vào thiết bị. Ưu tiên trước là giám sát tình trạng sống cùng giám sát UPS và phía nguồn. Như đã thấy trong trường hợp mô hình, khoảng 57% sự cố có nguyên nhân từ điện, nên chỉ lắp giám sát tình trạng sống mà không nhìn phía nguồn thì những lần khởi động lại không rõ nguyên nhân vẫn tiếp diễn. Nếu UPS chưa có thẻ quản lý mạng thì hãy bổ sung ở bước này. Giám sát hiệu năng và giám sát nhật ký làm sau cũng được.

Bước 4 là chốt ngưỡng và đường thông báo. Hãy thu thập dữ liệu từ bước 3 trong một khoảng thời gian rồi kẻ ngưỡng khi đã thấy biên độ dao động ở trạng thái bình thường. Đồng thời hãy quyết đường thông báo cho giờ làm việc ngày thường, cho ban đêm và ngày nghỉ, và cho đầu mối liên hệ thứ cấp, rồi thiết lập phân loại theo mức độ quan trọng. Và nhất định phải cố ý tạo ra một bất thường thử nghiệm để xác nhận rằng thông báo có tới nơi. Số trường hợp đặt một đường thông báo không tới nơi rồi cứ thế vận hành nhiều đến mức đáng kinh ngạc.

Trong 4 bước, bước 1 và 2 là thiết kế, bước 3 và 4 là xây dựng và vận hành. Và hiệu quả chỉ xuất hiện khi đã tới bước 4. Nhà máy dừng ở bước 3, tức đã có công cụ giám sát nhưng cảnh báo không tới ai cả, đang ở trạng thái đã bỏ tiền đầu tư mà không thu được hiệu quả. Ngay từ khâu lập kế hoạch triển khai, hãy coi cả 4 bước là một dự án duy nhất.

Câu hỏi thường gặp

Giám sát hệ thống nhà máy nên bắt đầu từ đâu

Hãy bắt đầu từ giám sát tình trạng sống và giám sát phía nguồn điện. Giám sát tình trạng sống có cấu hình đơn giản nhất và bắt được sự cố gây tổn thất lớn nhất là ngừng hoàn toàn. Phía nguồn điện có mức ưu tiên cao như một điều kiện đặc thù của nhà máy tại Thái Lan. Trong trường hợp mô hình, 8 trong 14 sự cố mỗi năm, tức khoảng 57%, có nguyên nhân từ chất lượng điện. Giám sát hiệu năng và nhật ký đều hữu ích, nhưng thiết kế ngưỡng cần dữ liệu ở trạng thái bình thường, nên trình tự thực tế là lắp giám sát tình trạng sống trước rồi vừa thu dữ liệu vừa chuẩn bị. Ngoài ra, hãy hoàn tất việc kiểm kê đối tượng và định nghĩa bình thường là gì trước khi chọn công cụ.

Triển khai giám sát thì phát hiện sự cố nhanh hơn bao nhiêu

Trong ước tính của trường hợp mô hình, trạng thái phụ thuộc báo cáo người dùng với thời gian trung bình 2.4 giờ đã giảm xuống trung bình 9 phút, tức 0.15 giờ, nhờ giám sát tình trạng sống cùng cảnh báo theo ngưỡng. Mỗi vụ rút ngắn 2.25 giờ, tỷ lệ rút ngắn khoảng 94%. Tuy nhiên, thứ giám sát rút ngắn chỉ là thời gian cho đến khi phát hiện, còn thời gian từ lúc phát hiện đến lúc khôi phục xong thì không đổi. Và nếu chưa xác định người nhận thông báo vào ban đêm và ngày nghỉ thì dù phát hiện nhanh hơn, thời điểm bắt đầu xử lý cũng không sớm hơn. Muốn có hiệu quả thì phải triển khai kèm cả thiết kế đường thông báo.

Chi phí giám sát có thể hoàn vốn chỉ bằng việc rút ngắn thời gian phát hiện không

Trong trường hợp mô hình thì không hoàn vốn được. Thời gian rút ngắn mỗi năm là 14 vụ nhân 2.25 giờ, bằng 31.5 giờ, nhân với chi phí 1,660 THB cho mỗi giờ không phát hiện được hiệu quả 52,290 THB mỗi năm. Trong khi đó, phí dịch vụ giám sát mỗi năm là 28,000 THB mỗi tháng nhân 12 tháng, bằng 336,000 THB, cộng thêm chi phí ban đầu 180,000 THB. Lấy hiệu quả chia cho phí dịch vụ năm chỉ được 15.6%. Giá trị của giám sát nằm nhiều hơn ở hiệu quả chặn những bất thường nhỏ trước khi chúng lớn lên thành lần ngừng lớn, nhưng vì hiệu quả đó phụ thuộc vào giả định xác suất nên bài viết này cố ý không quy ra tiền.

Có UPS thì có phòng được sự cố do điện không

Có UPS và chịu được sụt áp tức thời là hai chuyện khác nhau. Trong điều kiện nhiệt độ phòng ở Thái Lan, pin trong UPS có xu hướng lão hóa nhanh, nói chung lão hóa trong khoảng 1 năm, nên việc kiểm tra và xác nhận thay pin 1 lần mỗi năm được xem là mốc tham chiếu. Pin lão hóa không biểu hiện dấu hiệu nào ở trạng thái bình thường, việc thiếu dung lượng chỉ lộ ra khi sụt áp thực sự ập đến và thiết bị chuyển sang chạy pin. Do đó điểm quyết định không phải là có lắp UPS hay không, mà là đã đưa độ lành mạnh của pin và số lần chuyển mạch vào danh sách giám sát hay chưa. UPS không gắn thẻ quản lý mạng thì có thông tin nhưng không đưa ra ngoài được.

Lưu nhật ký giám sát có điểm nào cần lưu ý theo PDPA không

PDPA của Thái Lan có hiệu lực đầy đủ từ ngày 1 tháng 6 năm 2022, và việc xử lý dữ liệu liên quan đến theo dõi hành vi của chủ thể dữ liệu được xem là có thể nằm trong phạm vi điều chỉnh. Tuy vậy, không thể khẳng định nhật ký giám sát nhất thiết là dữ liệu cá nhân. Tỷ lệ sử dụng CPU và thời gian phản hồi không gắn với cá nhân, nhưng nhật ký truy cập có chứa mã người dùng thì có thể gắn được. Về mặt thực hành, hãy quyết 3 điều ngay khi triển khai, gồm đặt thời hạn lưu trữ theo mục đích rồi xóa khi hết hạn, giới hạn quyền truy cập bảng điều khiển, và không thu thập những trường không cần cho xử lý sự cố. Phán đoán cho từng trường hợp cụ thể xin hỏi ý kiến chuyên gia.

Tóm tắt

Xin sắp xếp lại những điểm chính.

Thứ quyết định tổn thất của sự cố công nghệ thông tin trong nhà máy không phải nguyên nhân mà là thời gian cho đến khi nhận ra. Thời gian dành cho công việc khôi phục bị ràng buộc bởi giới hạn kỹ thuật, nhưng thời gian cho đến khi phát hiện thì rút ngắn được bằng cơ chế. Và chừng nào còn phụ thuộc vào báo cáo của người dùng thì những lần ngừng vào ban đêm và ngày nghỉ về nguyên tắc là không thể phát hiện.

Giám sát hệ thống chia thành 3 loại là tình trạng sống, hiệu năng và nhật ký, mỗi loại bắt được một giai đoạn khác nhau. Và với nhà máy tại Thái Lan còn có lớp thứ 4 độc lập với cả 3 loại đó, là chất lượng điện. Sụt áp tức thời không thể bắt bằng giám sát tình trạng sống, và nếu không theo dõi độ lành mạnh của pin UPS thì bản thân việc có UPS cũng không bảo đảm khả năng chịu sụt áp.

Trong ước tính của trường hợp mô hình, một nhà máy gia công chi tiết kim loại ở tỉnh Ayutthaya có 14 sự cố mỗi năm, trong đó 8 vụ, tức khoảng 57%, có nguyên nhân từ chất lượng điện. Theo mùa thì mùa mưa có 9 vụ và mùa khô có 5 vụ, và độ lệch này gần như hoàn toàn đến từ phía nguồn điện. Thời gian cho đến khi phát hiện trung bình là 2.4 giờ, khi lắp giám sát tình trạng sống cùng cảnh báo theo ngưỡng thì giảm còn trung bình 9 phút, tức 0.15 giờ, rút ngắn 2.25 giờ mỗi vụ, tỷ lệ khoảng 94%. Thời gian rút ngắn mỗi năm là 31.5 giờ, nhân với chi phí 1,660 THB cho mỗi giờ không phát hiện được hiệu quả 52,290 THB mỗi năm.

Ở chiều ngược lại, chi phí giám sát là 180,000 THB ban đầu và 28,000 THB mỗi tháng, tức 336,000 THB mỗi năm. Lấy hiệu quả chia cho phí dịch vụ năm chỉ được 15.6%, nghĩa là chỉ riêng hiệu quả rút ngắn thời gian phát hiện thì chưa hoàn vốn đầu tư. Chúng tôi có thể làm con số này trông đẹp hơn, nhưng làm vậy thì nó không còn là dữ liệu để quyết định nữa, nên chúng tôi trình bày đúng như nó vốn có. Giá trị thật của giám sát nằm ở hiệu quả chặn những bất thường nhỏ trước khi chúng lớn lên thành lần ngừng lớn. Nhưng vì hiệu quả đó phụ thuộc vào giả định xác suất nên bài viết này không quy ra tiền. Tất cả đều là ước tính riêng của chúng tôi và không phải số liệu của doanh nghiệp có thật, nên xin hãy nhìn vào cách cộng dồn và ranh giới của việc gọi cái gì là hiệu quả, hơn là nhìn vào bản thân số tiền.

Có 3 thứ phải quyết trong thiết kế. Đo cái gì, tới mức nào là bất thường, và sau khi phát hiện thì gửi đi đâu. Cả 3 điều này đều quyết được độc lập với việc có thuê ngoài giám sát hay không. Bàn chuyện thuê ngoài trước mà không đi tới đâu chính là vì 3 điều này chưa được quyết.

Cách tiến hành gồm 4 bước là kiểm kê đối tượng, định nghĩa theo đơn vị chức năng nhìn từ người dùng, triển khai giám sát tình trạng sống và giám sát nguồn điện, và chốt ngưỡng cùng đường thông báo. Trạng thái đã có công cụ giám sát nhưng cảnh báo không tới ai là trạng thái đã bỏ tiền đầu tư mà không thu được hiệu quả. Và cuối cùng, nhất định hãy cố ý tạo ra một bất thường rồi xác nhận rằng thông báo có tới nơi.

Trước hết, xin hãy viết ra trong 1 năm vừa qua công ty mình đã có bao nhiêu sự cố, và mỗi lần không ai hay biết trong bao nhiêu giờ. Khi số vụ và số giờ được đặt cạnh nhau, bạn đã có một nửa dữ liệu cần thiết để phán đoán có nên đầu tư vào giám sát hay không.

Đang ở giai đoạn chưa quyết được nên giám sát cái gì cũng không sao. TOMAS TECH thiết kế và vận hành hạ tầng công nghệ thông tin cho các nhà máy Nhật Bản tại Thái Lan, và sẵn sàng nhận tư vấn ngay từ khâu kiểm kê đối tượng giám sát và cùng định nghĩa bình thường nghĩa là gì. Chúng tôi hoan nghênh cả những trao đổi không đặt tiền đề sẽ triển khai hệ thống, vì vậy nếu bạn muốn trước hết chuyển các sự cố của mình thành con số, xin liên hệ qua trang liên hệ.

Thông tin tham khảo

• JETRO – Thực trạng thiếu hụt nhân lực và cách ứng phó, cùng với xu hướng lương tối thiểu trong tương lai tại Thái Lan, khảo sát về thiếu hụt nhân lực công nghệ thông tin tại doanh nghiệp Nhật Bản, tiếng Nhật
• ASPIC – So sánh 12 dịch vụ MSP, nội dung cung cấp và lợi ích ra sao, cấu trúc phân tầng của dịch vụ giám sát thuê ngoài, tiếng Nhật
• OutageCost.com – Cost of IT Downtime, khảo sát tổn thất do ngừng hệ thống ở doanh nghiệp lớn
• Biz Info Log – Ngay ở khu vực đô thị Bangkok cũng cần lưu ý, tại Thái Lan sụt áp tức thời phổ biến hơn mất điện, tần suất sụt áp tức thời tại Thái Lan, tiếng Nhật
• Thai Jiyu Land – Chuyên mục số 254 của PC Support Thailand về biện pháp ứng phó mất điện, mất điện mùa mưa và lão hóa pin UPS, tiếng Nhật
• KPMG – Hỗ trợ tuân thủ Luật Bảo vệ Dữ liệu Cá nhân của Thái Lan PDPA, nghĩa vụ theo PDPA và bổ nhiệm DPO, tiếng Nhật
• One Asia Lawyers – Các vụ việc thực thi Luật Bảo vệ Dữ liệu Cá nhân PDPA tại Thái Lan, chế tài và thực thi PDPA, tiếng Nhật