Mình viết gần như mọi thứ ra giấy, và mình muốn bảo vệ cái thói quen đó bằng số đếm thay vì cảm xúc, vì "tài liệu quan trọng lắm" là loại câu ai cũng gật đầu mà không ai chi tiền.
Những gì đang tồn tại, đếm trực tiếp trong repo: khoảng bảy mươi runbook trải trên ba repo. 4.086 dòng prompt runbook. 985 dòng tài liệu vận hành. Bảy sơ đồ flow và mười tám user story viết ngược từ code của một approval engine ra, đi kèm mười một mã lỗi được tài liệu hoá của nó. Một cái mục lục mà mỗi dòng mang một nhãn mức sát thương. Đó không phải một văn hoá tài liệu mình được thừa kế. Đó là thứ mình tự xây, từng quy trình một, vì những lý do hoàn toàn ích kỷ và hoàn toàn thực dụng.
Một cái đầu là một điểm hỏng đơn lẻ có lịch nghỉ phép
Điều kiện xuất phát là một đống quy trình lặt vặt nằm trong đúng một cái đầu — đầu mình. Dựng lại một booking hỏng từ log của nó thế nào. Query một database mà client tiêu chuẩn không kết nối tới được ra sao. Một tính năng đa repo phải merge theo thứ tự nào.
Một quy trình sống trong đầu một người có cùng hình dạng với mọi điểm hỏng đơn lẻ khác, cộng thêm một thuộc tính: nó biết nghỉ phép. Mọi cuộc nói chuyện về uptime mà ta dành cho service, đáng ra ta phải dành cho kiến thức. Không ai dám ship một hệ thống mà toàn bộ state nằm trong một process không restart được; vậy mà ta ship đều đặn những cái team được xây đúng kiểu đó. Cái thói quen viết, xét tận gốc, chỉ là kỹ thuật làm dự phòng áp lên cái phần của hệ thống mà tối đến thì đi về nhà.
Khoảnh khắc runbook trở thành chính cái tool
Cái thói quen thôi ngốn ý chí kể từ ngày runbook và cái tool chạy nó trở thành cùng một file. Một slash command là một file markdown mà phần thân chính là prompt; không còn trang wiki riêng nào phải giữ cho khớp, vì bản thân tài liệu là thứ chạy được. Viết quy trình ra không phải bước chuẩn bị cho việc ship cái tự động hoá. Nó chính là ship cái tự động hoá.
Cú sập nhập đó hoá giải luôn lời phản đối kinh điển với tài liệu — "thà dành thời gian đó đi build tool" — vì không còn hai lựa chọn khác nhau để mà chọn.
Cái gì thật sự được đọc
Theo kinh nghiệm của mình, tài liệu được đọc vì đúng hai lý do: hoặc chạy nó thì xong việc, hoặc nó được đánh chỉ mục bằng mức nguy hiểm nó mang.
Loại thứ nhất là các runbook. Không ai đọc chúng để giải trí; người ta đọc bằng cách thực thi chúng, và đó là kiểu đọc duy nhất giữ cho một tài liệu còn sống.
Loại thứ hai là lý do cái mục lục mang nhãn mức sát thương — 🟢 chỉ đọc, 🟠 có ghi, 🔴 deploy. Trong một bộ, đếm ra là mười bảy lệnh chỉ đọc, sáu lệnh ghi vào database production, và một lệnh deploy. Cái nhãn nằm ngay trên mục lục, không chôn trong thân bài, vì khoảnh khắc người ta cần nó là khoảnh khắc họ đang lướt một danh sách bốn mươi thứ và tự hỏi cái nào cắn được mình. Mức nguy hiểm là mẩu metadata duy nhất mà con người tra cứu một cách đáng tin cậy.
Cái gì mục ruỗng
Kiểu hỏng cũng dễ nhận mặt không kém: một tài liệu không ai chạy. Một trang wiki mô tả một quy trình, viết sau khi việc đã xong, không ai thực thi — trang đó sai chỉ sau vài tháng và không ai phát hiện ra, vì muốn phát hiện thì phải có người làm theo nó. Cái sai của nó không có trigger. Một runbook chạy được thì hỏng rất to ngay lần đầu tiên thế giới trượt ra khỏi chân nó, và được sửa, vì cái người mà nó hỏng trước mặt đang cần nó chạy. Mục ruỗng không phải hàm của tuổi tài liệu. Nó là hàm của tần suất thực thi, và một tài liệu có tần suất thực thi bằng không thì đã bắt đầu ruỗng ngay ngày được đăng.
Mười tám user story và bảy sơ đồ flow viết ngược từ code của cái approval engine là nước cờ phòng thân của mình cho cái loại không thực thi được: loại mô tả. Chúng được rút ra từ code, không phải từ trí nhớ về ý định, và điều đó ít nhất ghim chúng vào một thứ kiểm lại được — khi code và sơ đồ cãi nhau, có một hiện vật xác định để dựng lại từ đó.
Cái mục mình từ chối xoá
Mọi tài liệu dạng audit mình viết đều kết thúc bằng một mục bắt buộc: chỗ mình không chắc. Đó là đoạn văn khó chịu nhất khi viết và đáng giá nhất khi đọc.
Lập luận nằm ở cách sự cố lan truyền. Một tài liệu được tin như một khối; nó mất niềm tin cũng như một khối. Cách nhanh nhất để phá huỷ một tài liệu là để người đọc sau phát hiện ra con số họ vẫn coi là số đo hoá ra chỉ là ước tính — sau phát hiện đó, mọi khẳng định khác trong tài liệu đều thành khả nghi, kể cả những cái đúng. Một đoạn văn ghi rõ những chỗ chưa chắc là món bảo hiểm rẻ chống lại cú sập đó. Nó biến "tài liệu này có thể sai ở bất cứ đâu" thành "tài liệu này đã nói cho tôi biết chính xác nó có thể sai ở đâu".
Con số không có ở đây
Nhất quán với cái mục đó: bài này không có con số giờ-tiết-kiệm nào, vì không tồn tại con số nào như thế. Mình chưa từng đo thời gian cái thói quen này ngốn hay thời gian nó trả về, và mình sẽ không nặn ra một tỉ lệ đẹp đẽ từ cảm giác.
Cái mình đưa ra được là cùng loại khẳng định với mọi thứ ở trên — đếm được, dựng lại được. Các runbook tồn tại. Số dòng là thật. Những quy trình từng sống trong một cái đầu giờ sống trong các file, và năm nay, lần đầu tiên, câu trả lời cho một câu hỏi vận hành thường là một cái link nhiều hơn là một đoạn văn mình lại phải gõ ra từ trí nhớ. Cái đó mình cũng không đo. Nhưng bạn cứ hỏi bất kỳ ai trước kia từng phải đi hỏi mình.