Hệ thống có bốn trăm microservice. Con số đó không ai thiết kế ra, nó tích lại qua bảy năm, qua ba lần tái cấu trúc tổ chức, qua những đội đã giải tán nhưng service của họ vẫn chạy. Rồi một đêm thứ sáu, một service nhỏ phụ trách format địa chỉ giao hàng trả lời chậm đi hai giây, và hai giây đó lan ngược qua chuỗi gọi như nước tràn ngược ống, đến sáng thứ bảy thì trang thanh toán sập. Sau sự cố, lãnh đạo duyệt một khoản ngân sách hardening, nghĩa là on-call dày hơn, redundancy thật, load test định kỳ, mỗi thứ đều tốn người và tiền, nên khoản ngân sách chỉ đủ cho hai mươi service. Không phải bốn trăm, không phải một trăm. Hai mươi.
Câu hỏi đặt ra trong phòng họp nghe đơn giản đến mức không ai nghĩ nó là một câu hỏi: chọn hai mươi cái quan trọng nhất.
Lượt làm đầu tiên rất tự nhiên. Kéo metrics từ service mesh°, đếm xem service nào có nhiều caller trực tiếp nhất, xếp hạng, cắt ở vị trí hai mươi. Danh sách A ra đời, và đứng đầu là những cái tên ai cũng đoán được trước khi nhìn: auth, API gateway, user profile, payment. Danh sách trông đúng. Trông đúng vì nó khớp với trực giác của mọi người trong phòng, và chính sự khớp đó, lát nữa, sẽ là vấn đề.
Một kỹ sư ngồi cuối bàn hỏi một câu khác. Không phải service nào nhiều người gọi, mà là: nếu service này chết, bao nhiêu đường đi trong hệ thống đứt theo? Chạy lại với câu hỏi đó, ra danh sách B. Hai danh sách trùng nhau khoảng một nửa. Nửa còn lại của B là những service ít caller, không ai nhớ tên, có cái ba năm chưa được deploy lại, nhưng chúng là cây cầu duy nhất nối hai nửa hệ thống. Những nút giao mà mọi đường tốt đều phải chen qua, chỉ là chưa ai từng nhìn chúng từ trên cao.
Cuộc họp lẽ ra có thể dừng ở việc gộp hai danh sách. Nhưng đã có hai câu hỏi thì sẽ có câu thứ ba. Service nào gần mọi thứ nhất, tức là sự cố từ nó lan ra toàn hệ thống nhanh nhất? Đó là danh sách C, và nó lại khác. Rồi câu thứ tư: service nào được chính những service quan trọng phụ thuộc vào, kiểu quan trọng vì được kẻ quan trọng chống lưng? Danh sách D. Bốn câu hỏi, bốn danh sách, cùng một hệ thống, cùng một bộ dữ liệu, và không danh sách nào sai.
Phòng họp lúc đó tưởng mình đang tranh luận nên chọn hai mươi service nào. Thật ra họ đang tranh luận chữ quan trọng nghĩa là gì, và chưa ai nhận ra cuộc tranh luận đó đang diễn ra. Đó là cuộc tranh luận mà chương này dạy cách nhìn thấy, và cách kết thúc.
Phản xạ đếm kết nối xứng đáng được kể bằng sự tôn trọng, vì nó không hề ngây thơ. Đếm số kết nối trực tiếp của một node là độ đo duy nhất trong cả chương này tính được bằng một câu GROUP BY, không cần dựng graph trong bộ nhớ, không cần thuật toán, không cần thư viện. Nó có tên chính danh trong sách, degree centrality, và với rất nhiều bài toán nó đủ tốt. Người đếm degree không làm sai. Họ chỉ chưa biết rằng mình vừa chọn một định nghĩa, trong khi tưởng mình đang đo một sự thật.
Có những lúc degree là câu trả lời đúng. Khi mạng tương đối đồng nhất, không có cấu trúc ngầm nào đặc biệt, node nhiều kết nối đúng là node đáng chú ý. Khi câu hỏi thật sự là về khối lượng trực tiếp, service nào chịu tải nhiều nhất, tài khoản nào giao dịch với nhiều đối tác nhất, thì degree không phải proxy của câu trả lời, nó là câu trả lời. Và khi cần khoanh vùng nhanh trước khi đo kỹ, degree là vòng lọc đầu tiên rẻ nhất. Nếu chương này làm bạn ngại dùng degree thì chương này đã thất bại.
Chỗ degree gãy nằm ở một chỗ khác, và có thể vẽ ra bằng một hình đơn giản đến mức bạn vẽ được trong đầu. Hai cụm node dày đặc, mỗi cụm vài chục node nối nhau chằng chịt, và giữa hai cụm là đúng một node gầy gò, một bên nối vào cụm trái, một bên nối vào cụm phải. Degree của node đó bằng hai. Xếp hạng theo phép đếm, nó nằm gần chót bảng, dưới cả những node vô danh nhất trong hai cụm. Cắt nó đi, hệ thống đứt làm đôi.
Degree nhìn từng node và đếm hàng xóm của nó. Câu hỏi mất nó thì gãy gì lại là câu hỏi về toàn bộ bản đồ. Hai tầm nhìn này không khác nhau về độ chính xác, chúng khác nhau về bản chất, một cái nhìn trong bán kính một bước, một cái đòi nhìn thấy mọi con đường. Không có lượng dữ liệu nào, không có cách đếm tinh vi nào ở bán kính một bước bù được cho việc không nhìn bản đồ.
Nhưng cái bẫy thật của degree không nằm ở tầng kỹ thuật, nó nằm ở tầng tổ chức. Trong hầu hết các đội mình từng thấy, degree không được chọn vì ai đó đặt bốn định nghĩa lên bàn rồi cân nhắc. Nó được chọn vì nó là cái dễ tính nhất, vì nó ra được trước cuộc họp chiều nay. Định nghĩa của chữ quan trọng bị quyết định bởi độ khó của câu SQL, thay vì bởi câu hỏi mà business thật sự cần trả lời. Quyết định lớn nhất của cả bài toán được đưa ra trong im lặng, bởi sự thuận tay.
Vậy bước tiếp theo không phải là bỏ degree. Bước tiếp theo là đặt nó vào đúng chỗ của nó, một thành viên trong một họ, mỗi thành viên trả lời một câu hỏi khác nhau. Việc cần học là bản đồ của cả họ.
Centrality không phải là một độ đo có nhiều cách tính. Nó là một họ câu hỏi mặc chung một chữ. Mỗi độ đo trong họ là một định nghĩa của chữ quan trọng được làm chặt đến mức tính được, và vì các định nghĩa khác nhau nên các con số trả về khác nhau, không phải vì cái này chính xác hơn cái kia, mà vì chúng đang trả lời những câu hỏi khác nhau. Điều đó đảo ngược quy trình quen thuộc. Không phải tính centrality rồi xem node nào điểm cao, mà là dịch chữ quan trọng trong miệng business thành một trong các câu hỏi dưới đây, rồi mới biết phải tính cái gì. Phép dịch bắt đầu bằng một câu hỏi ngược, và câu hỏi ngược đó là kỹ năng duy nhất của chương này: quan trọng để làm gì?
“Hỏi node nào quan trọng nhất là chưa hỏi xong câu hỏi. Quan trọng theo định nghĩa nào mới là câu hỏi.
”
Degree, như đã gặp, là định nghĩa thứ nhất: quan trọng nghĩa là nhiều kết nối trực tiếp. Trên graph có hướng nó tách làm hai, in-degree đếm ai trỏ tới mình, out-degree đếm mình trỏ tới ai, và hai con số đó đo hai loại quan trọng khác nhau, được tìm đến và có tầm với. Câu business nó trả lời: ai chịu tải trực tiếp lớn nhất, hub hiển nhiên nằm ở đâu. Chi phí: rẻ nhất họ, một lượt quét qua danh sách cạnh. Nó lừa bạn khi cấu trúc quan trọng hơn số lượng, và node cây cầu của phần trước là phản ví dụ thường trực, treo sẵn ở đó cho mọi lần bạn định tin phép đếm vô điều kiện.
Betweenness là định nghĩa thứ hai: quan trọng nghĩa là đứng giữa. Lấy mọi cặp node trong mạng, tìm các đường đi ngắn nhất giữa từng cặp, rồi đếm xem mỗi node nằm trên bao nhiêu trong số các đường đi đó. Node có betweenness cao là điểm mà mạng phải đi qua, dù không ai cố ý chọn nó. Chữ đường đi ngắn nhất ở đây chính là thứ chương trước vừa định nghĩa xong, kể cả bài học về weight đi theo nguyên vẹn, đường ngắn theo định nghĩa nào thì điểm nghẽn cũng theo định nghĩa đó. Câu business nó trả lời: mất node nào thì hệ thống đứt, chốt kiểm soát dòng chảy nằm ở đâu, single point of failure thật sự là cái nào. Chi phí: đắt nhất họ, vì phải tính đường đi ngắn nhất giữa mọi cặp, trên graph cỡ triệu node đây là bài toán tính bằng giờ hoặc bằng ngày, không phải bằng giây. Nó lừa bạn khi dòng chảy thật không đi theo đường ngắn nhất, tin đồn trong mạng xã hội không hỏi bản đồ trước khi lan, và betweenness ngầm giả định một mô hình dòng chảy mà bạn phải tự kiểm tra xem có khớp với domain° của mình không.
Closeness là định nghĩa thứ ba: quan trọng nghĩa là gần mọi thứ. Cộng khoảng cách từ một node đến mọi node khác, tổng càng nhỏ thì từ đây đi đâu cũng gần. Câu business nó trả lời thuộc họ đặt cái gì ở đâu: kho hàng nên nằm đâu để giao đi mọi vùng đều nhanh, cache đặt tầng nào, một thay đổi muốn lan khắp tổ chức thì nên bắt đầu từ ai. Chi phí: cùng cỡ đắt với betweenness, vì cũng cần khoảng cách giữa mọi cặp, và nó còn mang một điểm yếu kỹ thuật riêng, graph không liên thông làm định nghĩa gốc gãy, khoảng cách đến nơi không tới được là vô cực, nên các bản dùng thật đều phải vá. Nó lừa bạn trong những mạng có đường tắt dày đặc, nơi mọi node đều cách nhau vài bước, điểm closeness dồn cục sát nhau và thứ hạng không còn phân biệt được ai với ai.
Định nghĩa thứ tư bắt đầu bằng một bước lùi. Ba định nghĩa trên đều coi mọi kết nối nặng như nhau, một caller là một caller, một link là một link. Eigenvector centrality, và người họ hàng nổi tiếng nhất của nó là PageRank°, nói khác: quan trọng không nằm ở số kết nối mà ở chất kết nối. Được node quan trọng trỏ tới thì quan trọng theo. Định nghĩa này nghe luẩn quẩn, muốn biết điểm của A phải biết điểm của B, mà điểm của B lại tựa một phần vào A, nhưng sự luẩn quẩn này có lời giải hội tụ, cứ lan điểm số qua các cạnh đủ nhiều vòng thì mọi node lắng về một giá trị ổn định. Cơ chế đó đáng được kể bằng một câu chuyện thật hơn là bằng một đoạn toán, và câu chuyện đó là cả phần sau. Câu business nó trả lời: uy tín và sự tin cậy lan truyền, ai đáng tin vì được người đáng tin bảo lãnh, ảnh hưởng thật thay vì ảnh hưởng đếm follower. Chi phí: nằm giữa, đắt hơn degree nhiều, rẻ hơn betweenness nhiều ở quy mô lớn, vì lan điểm số vài chục vòng vẫn rẻ hơn tính đường đi giữa mọi cặp. Nó lừa bạn khi tạo node và cạnh là rẻ, vì lúc đó uy tín giả xây được bằng số lượng, và đó cũng là phần sau của chính câu chuyện kia.
Giờ quay lại phòng họp. Bốn danh sách A, B, C, D của buổi chiều hôm đó giờ có tên: degree, betweenness, closeness, eigenvector. Không danh sách nào đúng hơn danh sách nào. Mỗi danh sách đúng với một câu hỏi, và việc của người trong phòng không phải là chọn danh sách, mà là chọn câu hỏi. Chọn độ đo là chọn định nghĩa của chữ quan trọng, và định nghĩa đó là một quyết định business mặc áo kỹ thuật. Người ký duyệt hai mươi service phải là người hiểu mình vừa ký vào định nghĩa nào, vì ngân sách sẽ chảy theo định nghĩa đó chứ không chảy theo con số.
| Độ đo | Câu hỏi nó trả lời | Chi phí tương đối | Mù ở chỗ nào |
|---|---|---|---|
| Degree | Ai nhiều kết nối trực tiếp nhất | Rẻ nhất, một lượt quét | Không thấy cấu trúc, node cầu degree thấp |
| Betweenness | Mất ai thì nhiều đường đi đứt nhất | Đắt nhất, mọi cặp đường đi | Giả định dòng chảy theo đường ngắn nhất |
| Closeness | Từ ai đi mọi nơi gần nhất | Đắt, cần khoảng cách mọi cặp | Mạng nhiều đường tắt làm điểm dồn cục |
| Eigenvector / PageRank | Ai được kẻ quan trọng tin | Trung bình, lặp đến hội tụ | Bơm được nếu tạo node và cạnh rẻ |
Web cuối những năm chín mươi là một nơi rất dễ thắng nếu bạn là spammer. Các công cụ tìm kiếm thời đó xếp hạng chủ yếu bằng nội dung của chính trang, từ khoá xuất hiện bao nhiêu lần, ở tiêu đề hay ở thân bài, đậm hay thường. Muốn leo hạng cho từ khoá nào, nhét từ khoá đó vào trang thật nhiều, có người nhét cả đoạn chữ trắng trên nền trắng để máy đọc được mà người không thấy. Kết quả tìm kiếm thời đó phản ánh đúng cuộc chơi: trang hiện lên đầu thường là trang cố hiện lên đầu, không phải trang đáng đọc. Vấn đề thực chất là một bài toán centrality chưa được gọi tên. Trong hàng triệu trang cùng chứa một từ khoá, trang nào quan trọng?
Brin và Page nhìn web theo một cách mà bây giờ nghe hiển nhiên nhưng lúc đó thì không: web là một graph, trang là node, link là cạnh. Và họ đọc cái link theo nghĩa xã hội của nó. Một người đặt link đến trang khác là đang nói với độc giả của mình rằng chỗ này đáng xem, tức là mỗi link là một phiếu bầu. Bước đầu tiên từ quan sát đó là đếm phiếu, trang nào được nhiều trang khác trỏ tới thì quan trọng. Đó chính là in-degree, và nó hỏng theo đúng cách degree luôn hỏng, chỉ là lần này cuộc tấn công có động cơ tài chính: muốn nghìn phiếu thì tạo nghìn trang rác trỏ về mình, chi phí gần bằng không.
Bước nhảy nằm ở câu tiếp theo, và nó là một bước nhảy về modeling chứ không phải về thuật toán: phiếu bầu không bình đẳng. Phiếu của một trang quan trọng phải nặng hơn phiếu của một trang vô danh, và sự quan trọng của trang bầu lại được định nghĩa bằng đúng quy tắc đó, đệ quy. Nghe như định nghĩa cắn đuôi chính nó, nhưng có một cách hình dung làm sự luẩn quẩn tan ra. Tưởng tượng một người lướt web vô định, đi theo link mãi, thỉnh thoảng chán thì nhảy đại sang một trang bất kỳ rồi lại đi tiếp. Điểm PageRank của một trang là xác suất bắt gặp người đó đang đứng ở trang ấy, sau khi họ đã lang thang đủ lâu. Trang được nhiều nơi quan trọng trỏ tới là trang mà người lướt vô định kiểu gì cũng dạt về, và con số đó hội tụ, đếm được, xếp hạng được.
Đặt vào ngôn ngữ của phần trước, cái Google thắng ở thời điểm đó không phải là thuật toán nhanh hơn. Họ thắng cuộc thi định nghĩa chữ quan trọng. Eigenvector thắng degree, vì định nghĩa của họ đắt hơn để làm giả: muốn bơm điểm thì phải có trang quan trọng trỏ về mình, mà trang quan trọng không tự dưng trỏ về trang rác. Cùng một graph, cùng một bộ link, hai phép đo, và khoảng cách giữa hai phép đo đủ rộng để một bên trở thành công cụ tìm kiếm tốt nhất thế giới còn bên kia bị spam nhấn chìm. Một định nghĩa quan trọng được chọn khéo đáng giá một công ty, theo nghĩa đen.
Nhưng câu chuyện chỉ trung thực khi kể cả nửa sau. Một định nghĩa thắng thì trở thành mục tiêu. Khi cả ngành web hiểu ra rằng link là tiền, link trở thành hàng hoá, người ta dựng các link farm, những mạng hàng nghìn trang trỏ chéo nhau để bơm điểm cho nhau, mua bán link thành một nền kinh tế ngầm có bảng giá, và Google bước vào một cuộc rượt đuổi cập nhật thuật toán kéo dài hàng thập kỷ, đến giờ chưa xong. Hiện tượng này có tên từ trước khi web ra đời, một độ đo trở thành mục tiêu thì hết là độ đo tốt, và centrality không được miễn trừ, vì centrality chính là một metric, một metric chấm điểm thẳng vào thứ có giá trị.
PageRank dạy hai bài học, không phải một. Định nghĩa hay tạo ra giá trị thật, và cùng lúc đó tạo ra động cơ tấn công thật. Hệ thống tiếp theo sống trong một thế giới mà kẻ tấn công còn chủ động hơn nhiều, và họ rút ra một kết luận khác hẳn về việc nên trao cho một độ đo bao nhiêu quyền lực.
Một tài khoản mới đăng ký trên một nền tảng thanh toán. Giấy tờ sạch, email bình thường, giao dịch đầu tiên là một món hàng giá vừa phải, không có rule nào trên thuộc tính của chính nó bắt được gì. Nhưng nó đăng nhập từ một thiết bị từng chạm vào ba tài khoản đã bị khoá vì gian lận, dùng thẻ chung dải phát hành với một lô thẻ xấu tháng trước, và địa chỉ giao hàng trùng với hai tài khoản đang bị điều tra. Từng tín hiệu lẻ đều yếu, đều có lời giải thích vô tội. Vị trí của nó trong mạng lưới thì gào lên. Nếu bạn đọc chương một, đây chính là họ hàng của bài toán mà PayPal từng giải bằng cách lần tay theo mạng tài khoản liên kết, chỉ là giờ nó có khung khái niệm để gọi tên.
Các hệ thống chống gian lận thanh toán, Stripe Radar là một đại diện có tài liệu công khai, dựng một graph nối tài khoản với những thứ tài khoản chạm vào: thiết bị, thẻ, địa chỉ, email. Hai tài khoản dùng chung một thiết bị là hai node nối nhau qua node thiết bị đó, và quyết định coi cái gì là node, cái gì là cạnh ở đây lại là một quyết định mô hình hoá đang chạy ngầm, như mọi khi. Trên graph đó, hệ thống đo vị trí: tài khoản này cách các node đã gắn nhãn xấu mấy bước, vùng lân cận của nó dày đặc nhãn xấu đến đâu, nó có đang là điểm hội tụ của nhiều tín hiệu rủi ro không. Tên gọi thẳng thắn của kỹ thuật này là guilt-by-association, có tội vì quen biết, và cái tên đó nghe đáng sợ đúng như nó nên nghe.
Chữ đáng tiền trong cách các hệ thống này vận hành là chữ có kiểm soát. Các tín hiệu vị trí không trở thành phán quyết. Chúng đi vào mô hình chấm điểm như feature, đứng cạnh hàng trăm feature khác, ra một điểm rủi ro liên tục, và điểm đó dẫn đến yêu cầu xác minh thêm hoặc đưa vào hàng chờ review, trước khi bất kỳ cái gì bị khoá. Lý do không nằm ở kỹ thuật mà nằm ở nhận thức về sai số. Kết nối với node xấu có vô số lời giải thích vô tội, chiếc máy tính gia đình nhiều người dùng chung, địa chỉ của một khu chung cư, quán net, thẻ quà tặng qua tay. Nên định nghĩa quan trọng theo vị trí ở đây chỉ được phép nâng xác suất, không được phép kết tội. Đặt cạnh PageRank thì thấy rõ hai cái giá khác nhau: Google có thể trao cho định nghĩa của mình toàn quyền xếp hạng, vì giá của một kết quả xếp sai là người dùng bấm vào link thứ hai; ở đây giá của một điểm số sai là khoá nhầm dòng tiền, đôi khi là sinh kế, của một người thật.
Và cuộc rượt đuổi của phần trước cũng có mặt ở đây, chủ động hơn. Fraudster đọc được logic này. Họ pha loãng vị trí của mình, thiết bị mới cho mỗi tài khoản, danh tính tổng hợp được nuôi nhiều tháng cho sạch sẽ trước khi dùng, hạn chế tối đa số lần chạm vào các node đã bẩn. Đó là link farm của thế giới thanh toán, một cuộc tấn công nhắm thẳng vào độ đo. Bên phòng thủ đáp lại không phải bằng cách tìm một độ đo đúng hơn, mà bằng cách đo trên nhiều loại cạnh và nhiều định nghĩa gần xa cùng lúc, vì mỗi định nghĩa mù một chỗ và các điểm mù không trùng nhau. Bài học của cả chương quay lại ở dạng vận hành: không tồn tại định nghĩa đúng duy nhất để chọn một lần rồi xong, chỉ tồn tại việc biết từng định nghĩa mù ở đâu để bù bằng cái khác.
Hai hệ thống, hai kết luận về quyền lực của một con số. Một bên trao toàn quyền và chấp nhận sống cùng cuộc rượt đuổi công khai. Một bên giữ con số ở ghế cố vấn, mọi phán quyết phải qua thêm một lớp người hoặc một lớp xác minh. Cả hai đều đúng, với cái giá sai của domain mình. Đó cũng là câu kiểm tra mang về được cho mọi bài toán centrality từ giờ về sau: trước khi giao con số cho một hệ thống tự động hành động, hỏi giá của một điểm số sai là gì.
Cách hỏng thứ nhất xảy ra trước khi thuật toán chạy, và vì thế không thuật toán nào cứu được. Điểm số chạy ra, xếp hạng trông hợp lý, quyết định được đưa ra, và node quan trọng nhất hoá ra quan trọng theo một quan hệ chẳng liên quan gì đến câu hỏi. Đội đo điểm nghẽn vận hành trên graph dựng từ file khai báo dependency, service nào khai là gọi service nào, trong khi traffic thật ngoài production đã rẽ sang những đường khác từ hai năm trước. Centrality tính đúng tuyệt đối, trên một bản đồ sai. Chương ba đã nói cạnh là một quyết định mô hình hoá, và chương này chỉ thêm một điều: centrality khuếch đại quyết định đó, độ đo càng tinh vi thì lớp toán càng dày, và lớp toán dày che rất kỹ việc bên dưới nó là một bản đồ vẽ nhầm. Cách bắt: trước khi tin bảng xếp hạng, lấy ba node đứng đầu và kể bằng tiếng người tại sao chúng đứng đó, lần theo từng cạnh thật. Nếu lời kể phải viện đến chắc tại dữ liệu, vấn đề của bạn đang nằm ở graph, đừng đi tiếp ở độ đo.
Cách hỏng thứ hai là về chi phí, và về sự thành thật đi kèm chi phí. Con số mọi cặp của betweenness không phải chú thích lý thuyết, nó là hoá đơn. Job tính betweenness trên graph vài triệu node chạy quá đêm, rồi quá cuối tuần, rồi ai đó chuyển sang tính xấp xỉ bằng sampling, lấy mẫu một phần các cặp thay vì tất cả. Đến đây mọi thứ vẫn lành mạnh, sampling là lời giải đúng và là cách các thư viện lớn đều làm. Cái hỏng nằm ở bước cuối: con số xấp xỉ lên slide với bốn chữ số thập phân và không một dòng chú thích, vì chữ khoảng làm con số trông kém uy tín. Cách bắt là một quy ước báo cáo, mọi centrality tính bằng xấp xỉ phải nói rõ là xấp xỉ, kèm một phép thử ổn định, chạy lại với mẫu khác xem hai mươi node đứng đầu đổi mất mấy chỗ. Nếu thứ hạng đỉnh bảng đổi theo seed, quyết định của bạn đang đứng trên cát, và biết điều đó trước cuộc họp rẻ hơn nhiều so với biết sau.
Cách hỏng thứ ba nguy hiểm nhất, vì nó xảy ra sau khi mọi thứ kỹ thuật đã được làm đúng. Slide ghi: hai mươi service quan trọng nhất hệ thống. Không phải: hai mươi service mà nếu chết thì nhiều đường gọi đứt nhất, theo graph traffic tháng này. Con số đã rụng mất định nghĩa của nó ở đâu đó trên đường từ notebook lên slide, và từ giây đó trở đi phòng họp tranh luận về thứ hạng, sao service của đội tôi xếp mười chín, thay vì tranh luận về câu hỏi. Con số có trọng lực riêng của nó. Nó trông như kết quả đo đạc, mà đo đạc thì không ai chất vấn, trong khi toàn bộ chương này nói rằng nó là một lựa chọn được tính chính xác. Cách bắt là một quy tắc một dòng: không con số centrality nào rời khỏi đội mà không dính kèm câu hỏi nó trả lời, quan trọng nghĩa là gì, đo trên graph nào, tính lúc nào. Và một bài test ngược mà mình thấy hiệu nghiệm hơn mọi quy trình: nếu stakeholder không phản đối nổi định nghĩa, nghĩa là họ chưa hiểu nó. Một định nghĩa đã được hiểu thì luôn có thể bị tranh luận.
Còn một điều phải nói thẳng trước khi khép, vì nói ra nó hơi ngược với cả chương. Dưới vài trăm node, vẽ graph ra và nhìn thường thắng mọi độ đo. Node cây cầu của đầu chương, thứ mà degree bỏ sót và betweenness cần cả một phép tính mọi cặp để tìm ra, nhảy vào mắt người nhìn trong một giây, không cần định nghĩa nào. Mắt người còn thấy được những thứ chưa có độ đo nào gọi tên, một hình dạng lệch, một vùng thưa bất thường, một sự bất đối xứng khiến bạn khó chịu trước khi biết vì sao. Centrality sinh ra cho quy mô mà mắt chịu thua. Đừng rước nó về quy mô mà mắt đang thắng.
Nhưng nhìn bằng mắt không miễn trừ bài học của chương. Người nhìn vẫn đang chọn định nghĩa, chỉ là chọn ngầm, bằng trực giác, và với một câu hỏi trả lời một lần thì điều đó hoàn toàn lành mạnh. Khi quyết định cần lặp lại mỗi quý, hoặc cần bảo vệ trước người không nhìn cùng màn hình với bạn, sớm muộn định nghĩa ngầm cũng phải được gọi tên ra, và lúc đó bạn quay về họ bốn câu hỏi. Còn chiều ngược lại cũng có ranh giới của nó: mạng quá lớn để vẽ mà câu hỏi vẫn còn mơ hồ, chưa dịch nổi thành quan trọng để làm gì, thì đừng ép centrality gánh, vì có những câu hỏi về mạng không phải câu hỏi xếp hạng.
Phòng họp của đầu chương rồi cũng chốt được danh sách. Hai mươi service, kèm một dòng ghi rõ quan trọng ở đây nghĩa là đứt nhiều đường gọi nhất nếu chết, đo trên traffic production, và dòng đó cứu danh sách khỏi ba cuộc tranh cãi về sau. Ngân sách chạy, mọi người về chỗ. Nhưng nếu bạn là người ngồi lại cuối cùng, nhìn thêm một lúc vào cái graph bốn trăm node đó, bạn sẽ thấy một thứ mà không cột nào trong bảng xếp hạng mô tả. Có những nhóm service cứ dính lấy nhau, gọi nhau dày đặc bên trong và thưa thớt ra ngoài, như thể chúng thuộc về nhau theo một cách không nằm trong org chart, không trùng với tên đội nào, và không thứ hạng nào của bất kỳ node đơn lẻ nào nói lên điều đó. Câu hỏi về chỗ đứng của một node và câu hỏi về những node thuộc về nhau là hai loại câu hỏi khác nhau. Loại thứ hai chưa có tên trong chương này.