Khi ban lãnh đạo phớt lờ cảnh báo của IT, đội kỹ thuật đã tung đòn đáp trả mạnh mẽ
(theregister.com)Phản ứng mang tính bài học của đội IT
- Câu chuyện của "Bruce", người từng làm việc trong đội hạ tầng Internet của một ngân hàng tại Úc.
- Trong giai đoạn đầu của Internet banking, đội ngũ phát triển rất nhanh và khối lượng công việc cũng tăng lên.
- Trước khi mức sử dụng các đường truyền ISDN vượt quá một nửa, đội đã nhận ra cần mua thêm đường truyền và gửi đề xuất lên CIO.
Sự từ chối của ban lãnh đạo và phản ứng của đội IT
- CIO đã chuyển yêu cầu mua thêm đường truyền ISDN lên ban lãnh đạo, nhưng bị từ chối vì mức sử dụng hiện tại còn chưa đến một nửa.
- Khi mức sử dụng đường truyền vượt 50%, đội IT lại tiếp tục đề nghị, nhưng được chỉ đạo phải chờ đến khi gần chạm 100%.
Biện pháp chiến lược của đội IT
- Đội IT quyết định điều chỉnh kết nối mạng của ban lãnh đạo để khiến họ tự nhận ra vấn đề.
- Tuần đầu giảm 10%, sau đó mỗi tuần giảm thêm 10%.
- Một tháng sau, việc lắp thêm đường truyền ISDN được phê duyệt, và ban lãnh đạo tự chúc mừng vì đã giải quyết được "sự cố Internet".
Ý kiến của GN⁺
Điều quan trọng nhất trong bài viết này là đội IT đã thách thức quyết định của ban lãnh đạo và dùng trải nghiệm thực tế của người dùng để thuyết phục về khoản đầu tư hạ tầng cần thiết. Đây là một cách tiếp cận sáng tạo và hiệu quả để thu hẹp khoảng cách giữa vấn đề kỹ thuật và quyết định kinh doanh. Câu chuyện không chỉ thú vị với các chuyên gia IT mà còn chứa đựng bài học giúp những người ra quyết định không chuyên về kỹ thuật hiểu được tầm quan trọng của hạ tầng công nghệ.
1 bình luận
Ý kiến trên Hacker News
Trước đây tôi từng dùng một phần mềm bên thứ ba tệ hại, gây ra vấn đề lớn cho khách hàng
Chúng tôi đang làm một giải pháp thay thế nội bộ, nhưng một số người vẫn muốn gia hạn hợp đồng để tiếp tục dùng chính phần mềm đầy lỗi đó
Chúng tôi sắp xếp để mọi ticket do khách hàng mở đều chuyển cho phe muốn giữ giải pháp cũ, và cuối cùng sau khi chuyển sang hệ thống của chúng tôi thì hầu như không còn vấn đề gì nữa
Người làm thực tế thường anh hùng gồng gánh để nỗi đau không lan lên trên, và tổ chức thay vì loại bỏ vấn đề lại đổ người vào như thuốc giảm đau, rồi nghiện luôn trạng thái đó
Hệ thống cũ chẳng làm được gì ngoài những việc vốn có nếu không đại tu dây nối trên diện rộng, còn đội phụ trách thì tin rằng nếu không chia sẻ kiến thức thì công việc của họ sẽ được đảm bảo suốt đời
Hệ thống mới thì tin rằng thay vì sửa truy vấn chỉ cần thêm CPU là được, nên độ trễ cơ sở dữ liệu rất cao
Hai đội ngồi ngay cạnh nhau nhưng không nói chuyện với nhau, và đội hệ thống cũ thậm chí còn báo bưu kiện dưới gầm bàn giám đốc IT là bom
Cuối cùng đội hệ thống mới phải gọi Oracle, và Oracle đã viết lại truy vấn cho họ
Khả năng giải thích rủi ro một cách rõ ràng và nói được hệ quả kỹ thuật ảnh hưởng thế nào đến kinh doanh là năng lực cốt lõi với người làm IT
Có thể ban lãnh đạo ngân hàng này thật sự cực kỳ chậm hiểu, nhưng cũng có khả năng đội kỹ thuật đã không giải thích cho ra hồn
Có lẽ vì tôi ở trong IT, nhưng tôi thấy chúng tôi giao tiếp khá tốt và khá chính xác
Vấn đề thật sự là chính trị ở tầng quản lý trung gian làm mọi thứ méo mó đi
Trong nhóm thì có thể nói “tôi làm hỏng rồi nên phải sửa”, nhưng lên phía trên lại có những người viện đủ lý do để không phải đảo ngược ngay cả những quyết định không mấy quan trọng
Có khi ai đó đã bán với sếp rằng đống thiết bị đó còn dùng được thêm 10 năm nữa rồi
Làm việc với đồng nghiệp thì thấy họ rất cố gắng giải thích ở nhiều mức độ sâu khác nhau cho phù hợp với người nghe
Điều xảy ra thường xuyên hơn nhiều là CEO và các quản lý bên dưới họ đơn giản là không quan tâm
Trong đầu họ đã có sẵn một “kế hoạch vĩ đại”, và dù dev có nói bao nhiêu lần rằng ảo tưởng đó không thể thành hiện thực thì cũng không thay đổi được gì
Phần lớn họ hiểu hoàn toàn những gì chúng tôi nói
Không phải chúng tôi ném ra mấy thuật ngữ bí hiểm mà chỉ tầng lớp nerd cấp cao mới biết, mà đơn giản là họ không quan tâm
Tôi ước gì sẽ có ít hơn những người kiểu MBA lạnh lùng vô cảm điều hành công ty, và nhiều hơn các tổ chức nơi kỹ sư gánh trách nhiệm hơn, nhưng đời là vậy
IT doanh nghiệp phát triển từ công việc hỗ trợ khối văn phòng, và khi đó đâu cần hoạch định chiến lược gì để máy fax hay PC chạy được, nên ban đầu nó bị xem là bộ phận không quan trọng
Rất dễ cho rằng mấy người mặc vest keo kiệt, ngu ngốc, hay không hiểu công nghệ, nhưng thực tế nhiều khi lại là thiếu kỹ năng giao tiếp
Ở công việc đầu tiên của tôi, CFO liên tục từ chối yêu cầu về một hệ thống sao lưu tử tế cho AS/400
Trên cái AS/400 đó có ERP, CRM, kế toán và toàn bộ hoạt động của công ty, mà sao lưu công việc của 300 người lên đĩa mềm 8 inch thì ngay từ đầu đã là điều bất khả thi
Một ngày nọ xảy ra lỗi đĩa nghiêm trọng và cả công ty tê liệt suốt nhiều tuần, xử lý đơn hàng, yêu cầu hỗ trợ, đề xuất bán hàng, tra cứu số khách hàng và địa chỉ đều bị chặn
Tôi nhớ là một số ổ đĩa đã được gửi cho Kroll Ontrack
Chỉ sau thảm họa đó họ mới mua thiết bị sao lưu tử tế
Vài tháng sau, một lập trình viên sinh viên chạy truy vấn xóa trên production với mệnh đề
wheređã bị comment đi, và nguyên cả một bảng bị xóa sạchCó backup, nhưng một tác vụ nền phát hiện việc đó rồi tái tạo lại 4 năm hóa đơn, gửi email yêu cầu tính tiền lại cho toàn bộ khách hàng trong quá khứ
Môi trường test xuất hiện không lâu sau đó
Cách đây không lâu tôi làm ở một trường cao đẳng cộng đồng vùng xa, nơi toàn bộ dữ liệu nằm trên một AS/400 cũ kỹ và cứ vài tuần lại chết một hai ngày
Không có backup, ổ băng từ thì hỏng, còn các linh kiện như NIC 10Mbps lỗi thời đến mức ngay cả theo tiêu chuẩn thời đó cũng cũ rích thì chẳng có đồ thay
Tôi liên tục yêu cầu thay thế hoặc chuyển sang máy chủ đám mây nhưng chỉ nhận được câu trả lời “không có trong ngân sách”, “quá đắt”
Theo mức sử dụng thực tế thì chỉ vài trăm đô một tháng, so với rủi ro toàn trường sụp đổ và có thể phải đóng cửa vĩnh viễn nếu hệ thống chết thì thật vô lý
Rồi cuối cùng sự cố cũng xảy ra, và trong nhiều ngày nó vẫn truy cập được từ terminal chính nhưng hoàn toàn không giao tiếp được với mạng
Mọi người bắt đầu hoảng loạn, thậm chí có người nói nên gọi chuyên gia sửa AS/400 với giá hơn 100 đô mỗi giờ
Ở nỗ lực cuối cùng, tôi sửa được NIC, rồi vừa thông báo hệ thống sống lại vừa nhấn mạnh rằng đây có thể là lần khởi động cuối cùng của nó, nên phải sao lưu sang nơi khác trước khi quá muộn
Sáu tuần sau, chúng tôi có một AS/400 chạy trên đám mây sáng choang, rồi tổ chức lễ tiễn đưa khi tắt con quái vật nặng nề cũ kỹ đó lần cuối
Tổng thời gian hoạt động cuối cùng của nó là gần 25 năm
Có thể nói câu chuyện này khó có khả năng xảy ra hoặc hoàn toàn bịa đặt, nhưng tôi không nghĩ vậy
Muốn làm được việc gì đó trong một tổ chức lớn thì phải khiến ban điều hành cảm nhận được nỗi đau của mình
Không phải yếm thế đâu, thế giới vận hành như vậy
Ai kỳ vọng đối phương tự mình đi hết mọi bước tư duy để hiểu tình huống thì sẽ nhận lấy một cú bất ngờ khá phũ phàng
Ngay cả đầu những năm 90 thì ISDN bên ngoài các văn phòng chi nhánh cũng không phải thứ phổ biến
Hơn nữa, khi bắt đầu nhắc đến traffic shaping/QoS thì lại càng khó tin hơn
Theo tôi biết, phải lâu hơn nhiều sau đó các router Cisco 2500/2600 mà gần như ai cũng dùng thời đó mới hỗ trợ những tính năng như vậy
Có khi họ muốn nói đến T1, và khá đậm mùi r/thathappened
Theo định nghĩa, quản lý làm công việc khác với người thực thi
Ví dụ, làm sao để quản lý cảm nhận được nỗi đau của một codebase tệ hại?
Ở chỗ làm, chúng tôi từng cố tiết kiệm chi phí bằng cách không để router ISDN Cisco 1604 luôn kết nối mà đặt chế độ tự động quay số
Rồi phát hiện ra IBM AIX cài gói trình duyệt web cứ mỗi giờ lại thực hiện một cuộc gọi telemetry định kỳ về Big Blue, khiến mạng của phòng thí nghiệm không bao giờ rơi về trạng thái nhàn rỗi để ngắt kết nối
Chúng tôi thêm quy tắc tường lửa vào router để chặn trò lén lút đó
Ngay cả cuối thập niên 90, Microsoft, Sun và Novell cũng không trơ trẽn với telemetry như IBM
Vấn đề thật sự lộ ra ở đây là phía IT cần có quyền tự chủ để triển khai những việc mà họ biết là đúng, ở một mức độ nào đó độc lập với phía kinh doanh
Suy cho cùng, một tổ chức phải chịu bao nhiêu giám sát là do mức độ tin cậy quyết định
Ở nơi tôi làm, nếu không ảnh hưởng đến khách hàng thì không cần xin phép
Nếu máy móc có vẻ quá tải hoặc gói SaaS sắp chạm hạn mức thì cứ nâng cấp thôi
Thỉnh thoảng có người hỏi về hóa đơn mới hay chi phí tăng lên, nhưng không cần bị thẩm vấn hết lần này đến lần khác chỉ để làm công việc của mình
Những người mặc vest nên nghĩ đến mặt trái của một môi trường nơi ngay cả việc kỹ thuật nhỏ nhặt cũng phải đi van xin phê duyệt
Có bao nhiêu đổi mới đã bị ném thẳng vào thùng rác đang cháy chỉ vì các chính sách thay đổi phức tạp do tháp ngà dựng lên hơn 10 năm trước?
Liệu có thể nghĩ lại tổ chức theo hướng mô hình hóa bộ phận kinh doanh như khách hàng của đội IT không?
Nếu công ty thất bại thì tổ chức IT cũng chẳng còn lý do để tồn tại, nên cách nghĩ đó có vẻ đơn giản hơn nhiều
Vì vậy chi phí so với hiệu ích thay đổi, nên cần phải có giao tiếp
Mỗi khi thấy kiểu phản ứng như “việc của anh là tôn trọng quyết định của hệ thống cấp bậc”, tôi lại nghĩ đến việc các tổ chức doanh nghiệp vẫn còn mắc kẹt trong tư duy kiểu quân đội đến mức nào
Trong quân đội Phổ ngày xưa, nhiệm vụ được truyền đạt theo mục tiêu
Kiểu như “tôi đang cố đạt được X, anh phụ trách Y, đơn vị khác làm Z”, còn việc thực thi thì giao cho sĩ quan tại chỗ, người thực sự nhìn thấy hiện trường và có kiến thức cần thiết
Ngoài ra, nếu sĩ quan hay hạ sĩ quan phản đối mệnh lệnh của cấp chỉ huy trực tiếp thì họ cũng có thể khiếu nại lên cấp cao hơn
Cộng thêm cả hệ thống tham mưu, nơi sĩ quan tham mưu cũng phải có kinh nghiệm chỉ huy trong quá trình huấn luyện và thậm chí có thể vô hiệu hóa mệnh lệnh của chỉ huy, nó trở thành một hệ thống mạnh và linh hoạt để thích nghi với tình huống thay đổi
Các sĩ quan không ngần ngại tranh luận với cấp trên, leo thang lên cấp cao hơn, hoặc từ chối mệnh lệnh nếu họ thật sự cho là cần thiết
Vì như vậy mới tạo ra được sự đồng thuận và tham gia từ các cấp thấp hơn
Tức là ra quyết định ở cấp thấp nhất có thể
Đến thời hiện đại thì phần nào mất mốt, nhưng theo hiểu biết của tôi, không có quân đội nào vận hành thuần túy bằng kiểu “việc của anh là làm theo quyết định cấp bậc”
Ví dụ như cuốn Extreme Ownership
Có thể tôi quá ác ý, nhưng với kiểu lãnh đạo đó thì chắc tôi sẽ đơn giản đi tìm việc mới và để mặc cả con tàu chìm xuống
Nếu đơn giản hóa từ góc nhìn lãnh đạo, giả sử mỗi năm có 100 đề xuất tương tự được đưa lên và mỗi cái tốn 1 triệu USD
Thì ngay cả khi bỏ qua khấu hao hay trò lách thuế, đó vẫn là 100 triệu USD chi phí thuần mỗi năm
Dù là ngân hàng thì cũng là số tiền lớn và phải dùng có chiến lược chứ không thể lãng phí
Trong bối cảnh đó, khiến lãnh đạo cảm nhận được nỗi đau và hiểu theo bản năng vì sao 1 triệu USD lần này là khoản chi đúng đắn, là một chiến lược tương đối lành mạnh cho cả lãnh đạo, IT lẫn doanh nghiệp
Cũng cần nhớ rằng giám đốc điều hành là người quản lý thời gian, nhân sự, chi phí hữu hạn của công ty
Tất nhiên, nhìn chung họ không đặc biệt giỏi việc đó, và từ góc nhìn lợi ích thuần túy của công ty, lựa chọn hợp lý có lẽ là trả cho họ mức đãi ngộ bớt xa xỉ hơn, gần giống nhân viên bình thường
Nhưng không phải “công ty” ra quyết định mà là con người, và trong đó có trò chơi chính trị, động cơ khuyến khích và lợi ích cá nhân
Các giám đốc điều hành kiểm soát luồng thông tin, quyết định, tài nguyên và tiền bạc, nên họ hành xử như ký sinh trùng hút lấy phần quá mức từ công ty vật chủ
Cách giải quyết vấn đề này xin dành lại như một bài tập cho người đọc
Nếu thứ lãnh đạo nghe được chỉ là “chúng tôi dự đoán đường truyền sẽ bão hòa 50% vào khoảng ngày X”, thì IT thực sự đã giải thích rất tệ
Chúng ta biết rằng trong công nghệ này, bão hòa 50% đồng nghĩa với độ trễ cho khách hàng hoặc lỗi kết nối
Vậy thì phải nói là “chúng tôi dự đoán khách hàng sẽ gặp vấn đề kết nối vào khoảng ngày X”
Nếu biết rằng ngưỡng 100% chỉ là giá trị lý thuyết chỉ đạt được trong điều kiện lý tưởng, thì phải nói theo ngưỡng thực tế có thể sử dụng
Muốn người ta đưa ra quyết định dựa trên thông tin thì phải cung cấp đúng thông tin, và nếu phía được trả tiền để hiểu công nghệ là IT, thì truyền đạt các đặc tính đó theo cách mà những người mặc vest có thể hiểu cũng là việc của IT
Dĩ nhiên có thể họ đã làm hết sức, nhưng chỉ dựa vào bài viết này thì nghe giống như họ chỉ gửi một bản ghi nhớ mà không kèm những thông tin đó
Tôi không thực sự hiểu cách dùng cụm “mức sử dụng 50%” như thể chỉ mở vòi nước một nửa
Nếu tải dồn nhọn vào một đường ống duy nhất thì kiểu gì cũng sẽ xuất hiện suy giảm hiệu năng ngắt quãng, đúng không?
Tỷ lệ thời gian gặp “trải nghiệm tệ” có vẻ sẽ tăng vọt tùy theo phân bố, nên ngay cả 60% thôi cũng có lẽ đã khó chịu đựng nổi
So sánh thì giống như một quán bar quyết định chỉ bố trí 1 nhân viên phục vụ dựa trên nhu cầu trung bình, rồi tối thứ Sáu ập đến
Đó chính là điều công thức Kingman nói đến
“Khi mức sử dụng vượt 50%, đội IT lại đề xuất đặt thêm ISDN. Và một lần nữa bị từ chối. Kèm theo chỉ thị là đừng hỏi lại cho tới khi mức sử dụng tiến sát 100%.”
Điều này rất giống với cách giới chức nhìn nhận COVID
Có vẻ như những người chịu trách nhiệm chỉ nhìn xu hướng hiện có mà không dự báo được bất cứ điều gì, và chỉ phản ứng khi thảm họa đã ngay trước mắt