Sổ tay vận hành hàng tháng cho báo cáo backlink

Tại sao là hàng tháng thay vì hàng ngày

Biểu đồ của chúng tôi làm mới khoảng một lần mỗi tháng. Một công việc hàng ngày sẽ trả về cùng các con số.

Chạy thường xuyên hơn không làm cho báo cáo cập nhật hơn, nó chỉ làm cho việc giải thích trở nên tốn kém hơn. Một người đọc thấy 30 điểm giống hệt nhau sẽ cho rằng đường ống dữ liệu bị lỗi.

Chọn một ngày cụ thể mỗi tháng một cách có chủ đích, lý tưởng là một tuần sau khi bản cập nhật trước đó ổn định. Ghi ngày vào tên tệp, để lịch trình tự nó được ghi lại.

Chọn lịch trình trước và để báo cáo tuân theo nó. Một báo cáo tự xây dựng lại bất cứ khi nào ai đó mở sổ ghi chú sẽ không có ngày rõ ràng, điều đó rất khó để bảo vệ trong một buổi xem xét.

Cần lưu trữ những gì ngoài các con số

Một nửa báo cáo là siêu dữ liệu, vì vậy hãy lưu trữ nó cùng với các con số.

Ghi ngày kéo dữ liệu, tên hành động, các tham số (per, sort, order) và trường credits của phản hồi vào một tệp phụ nhỏ bên cạnh mỗi bản chụp. Sáu tháng sau, khi một đồng nghiệp hỏi tại sao tháng 10 khác với tháng 9, tệp đó sẽ trả lời trong mười giây thay vì cả buổi chiều.

Thêm commit git của kịch bản và các phiên bản gói từ renv. Một báo cáo không thể cho biết mã nào và trạng thái chỉ mục nào tạo ra biểu đồ chỉ là một ảnh chụp màn hình, không phải là một phân tích, bất kể tibble trông gọn gàng đến đâu.

Bố trí targets tối thiểu

Ba targets là đủ khi kế hoạch vẫn còn nhỏ.

Một target kéo dữ liệu từ API và ghi tệp có ngày, một target đọc tệp và xây dựng tibble, một target hiển thị tài liệu Quarto. Vì chỉ target đầu tiên chạm vào mạng, bạn có thể chạy lại các target khác ngoại tuyến bao nhiêu tùy thích và biểu đồ sẽ không thay đổi một cách tình cờ.

Ghim các phiên bản gói bằng renv, ghi lại thông tin phiên ở chân trang của báo cáo, và giữ bảng ngưỡng từ trang chấm điểm hàng loạt trong kho lưu trữ bên cạnh mã. Đối với khía cạnh tài chính, trang ngân sách cho bạn biết một tháng nên tốn bao nhiêu.

Khi có lỗi, hãy đọc mã trước. HTTP 401 có nghĩa là khóa không đúng hoặc bị thiếu. HTTP 402 có nghĩa là hết credits. Bất kỳ lỗi nào khác đều đáng được ghi lại đầy đủ. Bài phân tích bao gồm các giai đoạn đó, và ví dụ về join là một công việc đầu tiên tốt để lên lịch.

Học cách biết một lần chạy bị lỗi trước đồng nghiệp

Một báo cáo backlink có thể tái lập nhưng thất bại một cách âm thầm sẽ gây hiểu lầm nhiều hơn một báo cáo chưa từng chạy. Câu hỏi thực sự không phải là liệu công việc có thể thất bại hay không, mà là ai sẽ nghe thấy thông báo về lỗi đó nhanh như thế nào.

Làm cho công việc thất bại một cách rõ ràng

Một công việc được lên lịch sẽ thoát với trạng thái khác 0 khi một lệnh gọi trả về HTTP 401 hoặc 402, và bộ lên lịch đánh dấu lần chạy là thất bại. Đó là cảnh báo rẻ nhất mà bạn có, và nó không cần thêm dịch vụ nào.

Các lần kéo dữ liệu một phần là trường hợp nguy hiểm. Nếu kịch bản ghi tệp của nó sau khi twenty trong thirty chunk, tệp sẽ tồn tại và trông có vẻ ổn. Hãy ghi vào một tên tạm thời và đổi tên nó chỉ khi thành công.

Gửi một thông báo cho mỗi lần lỗi

Chọn một kênh cho các lỗi, chẳng hạn như email cho chủ sở hữu báo cáo hoặc tin nhắn trong nhóm chat. Hai kênh có nghĩa là hai nơi để kiểm tra, và khả năng cao là không ai kiểm tra cả hai.

Thông báo nên nêu rõ target bị lỗi, mã trạng thái và thời gian. Mọi thứ khác thuộc về nhật ký.

Kiểm tra xem đầu ra có hợp lý không

Một lần chạy có thể thành công nhưng vẫn sai. So sánh số hàng với tháng trước, và đánh dấu một sự sụt giảm vượt quá ngưỡng bạn đã chọn trước.

Kiểm tra có thể đơn giản là một phạm vi dự kiến. Mục tiêu là nhận ra một bản chụp bị thiếu dữ liệu trước khi biểu đồ được gửi đến khách hàng.

Chỉ định một chủ sở hữu cho báo cáo

Chỉ định một chủ sở hữu cho báo cáo. Một cảnh báo không có chủ sở hữu sẽ được mọi người đọc nhưng không ai hành động.

Chủ sở hữu không nhất thiết phải sửa công việc. Chủ sở hữu phải quyết định xem một báo cáo đến muộn có thể chấp nhận được không, và nói rõ điều đó trong chính báo cáo.

Ghi tên chủ sở hữu vào tiêu đề sổ tay vận hành, và cập nhật nó khi chủ sở hữu thay đổi. Một sổ tay vận hành với chủ sở hữu cũ là một mối nguy thầm lặng.

Chọn ngày và chạy công việc đầu tiên bằng tay

Thời gian và lần chạy đầu tiên quyết định liệu lịch trình có được duy trì hay không. Cả hai đều dễ bị sai trong tháng đầu tiên, và cả hai đều dễ dàng làm đúng.

Hai quyết định, được ghi lại một lần, sẽ tiết kiệm được nhiều tranh cãi nhất sau này. Quyết định đầu tiên là ngày. Quyết định thứ hai là nơi bộ hẹn giờ chạy. Cả hai đều thuộc về sổ tay vận hành, không phải trong đầu ai đó.

Chọn một ngày và ghi nó lại

Một ngày cố định trong tháng, chẳng hạn như ngày làm việc đầu tiên sau khi bản cập nhật đã ổn định, dễ giải thích hơn một dự đoán vào đầu tháng.

Đặt ngày vào chính tệp lịch trình, để thời gian là một phần của mã và không phải là một ký ức trong lịch của ai đó.

Chạy công việc đầu tiên bằng tay

Lần chạy được lên lịch đầu tiên nên là một lần chạy thủ công. Chạy kịch bản của bạn, đọc nhật ký, so sánh tệp với tệp trước đó, và chỉ sau đó mới bàn giao bộ hẹn giờ.

Lần chạy đầu tiên cũng kiểm tra kho lưu trữ bí mật. Một khóa hoạt động trên máy của bạn nhưng bị thiếu trong CI là lý do phổ biến cho lần chạy được lên lịch đầu tiên bị lỗi.

Giữ tệp sidecar trung thực

Tệp sidecar ghi lại những gì lần chạy đã làm. Nếu một người viết nó bằng tay, nó sẽ lệch khỏi lần chạy. Hãy để kịch bản ghi nó, và chỉ cho phép mọi người đọc nó.

Một tệp sidecar mà kịch bản chưa từng chạm vào chỉ là một ghi chú, không phải là một bản ghi, và báo cáo nên trích dẫn bản ghi.

So sánh tệp sidecar với tệp một lần mỗi tháng. Nếu các con số trong hai tệp không khớp, lần chạy đã thất bại theo một cách mà kịch bản không nhận ra.

Nơi bộ hẹn giờ sống

Một trình chạy được lưu trữ và một mục cron cục bộ sẽ thất bại theo những cách khác nhau. Một trình chạy được lưu trữ có thể bị tạm dừng bởi các cài đặt của chính nó, và một mục cron cục bộ sẽ dừng lại khi máy ở chế độ ngủ. Hãy kiểm tra xem bạn đã chọn cái nào, và kiểm tra bộ hẹn giờ một lần với một lịch trình ngắn trước khi lịch trình thực sự.

Bất kể bạn chọn cái nào, hãy ghi lại bộ hẹn giờ trong kho lưu trữ bên cạnh kịch bản, để người tiếp theo biết công việc nằm ở đâu.