Thiết lập công cụ xếp hạng miền cho bảng tính và tác vụ cron

Nơi thiết lập này thất bại

Sự im lặng là lỗi thường gặp. Một tác vụ cron bị lỗi trông giống hệt một tác vụ đã thành công.

Kiểm tra mã HTTP. Mã 401 có nghĩa là khóa bị thiếu hoặc sai, và mã 402 có nghĩa là tín dụng đã hết, vì vậy hãy cảnh báo về cả hai và khắc phục trước khi báo cáo tháng tiếp theo đến hạn.

Hãy nhớ rằng phân trang bị giới hạn ở độ sâu 50.000 hàng và rằng bulk_dr xử lý tối đa 2.000 miền mỗi lệnh gọi. Các danh sách dài hơn cần được chia nhỏ, đây là một vòng lặp bổ sung và tốn một tín dụng cho mỗi khối.

Kiểm tra bằng tay trước. Chạy dòng cron trong terminal, đọc tệp nhật ký và kiểm tra xem số dư đã giảm đúng bằng chi phí bạn dự kiến. Sau đó xem cách các số so sánh với gói suite và quyết định tần suất chạy.

Phiên bản hóa danh sách miền của bạn. Giữ tệp trong kho lưu trữ hoặc ổ đĩa chia sẻ có lịch sử, vì vậy khi một số thay đổi vào tháng Ba, bạn có thể xem liệu danh sách có thay đổi hay không. Thêm cột ghi chú cho các miền bạn đã thêm có chủ đích, chẳng hạn như một đối thủ mới hoặc một khách hàng đã đăng ký trong tháng. Hãy coi danh sách là dữ liệu có chủ sở hữu, vì lỗi rẻ nhất là lỗi bạn phát hiện trong bản diff.

Chia danh sách dài thành các khối

Các danh sách dài là nơi một thiết lập gọn gàng gặp giới hạn của nó. Một lệnh gọi hàng loạt xử lý tối đa 2.000 miền, vì vậy một danh sách 5.000 miền cần ba yêu cầu và việc phân chia phải xảy ra trước khi lệnh gọi đầu tiên được thực hiện.

Chia theo một quy tắc ổn định, chẳng hạn như thứ tự sắp xếp của cột miền. Theo cách đó, cùng một miền sẽ nằm trong cùng một khối mỗi tháng và việc so sánh vẫn giữ nguyên.

Danh sách trên 2.000 hàng

Ghi mỗi khối vào bảng tính dưới dạng một khối riêng biệt, với số khối ở cột đầu tiên. Một khối bị lỗi sau đó sẽ dễ dàng tìm thấy.

Mỗi khối tốn một tín dụng, vì vậy một danh sách 5.000 hàng tốn 3 tín dụng mỗi lần chạy, tương đương $0,0003. Một công cụ xếp hạng miền chỉ hữu ích như danh sách mà nó đọc, vì vậy hãy giữ danh sách đó gọn gàng.

Nếu danh sách tăng lên quá 5.000 hàng, hãy xem xét lại bố cục của bảng tính. Một tab mỗi tháng giúp mỗi lần chạy dễ đọc khi các hàng chồng chất.

Chạy lại một khối bị lỗi

Nếu khối hai trả về lỗi, hãy chỉ chạy lại khối hai. Chạy lại toàn bộ danh sách sẽ tiêu tốn tín dụng cho các hàng đã trả về.

Ghi số khối với mã trạng thái, để lần chạy lại là một dòng trong nhật ký, không phải là một cuộc tìm kiếm trong bảng tính.

Giữ bản đồ khối ổn định

Nếu thứ tự danh sách miền thay đổi, các khối sẽ di chuyển và việc so sánh hàng tháng sẽ bị phá vỡ. Sắp xếp danh sách trước khi chia nhỏ nó, mỗi lần.

Lưu trữ bản đồ khối bên cạnh danh sách.

Một bài kiểm tra đơn giản: chọn bất kỳ khối nào và đếm lại số hàng của nó so với danh sách. Một sự không khớp có nghĩa là bản đồ đã bị trôi, và điều đó rẻ hơn để tìm thấy trong bảng tính hơn là trong báo cáo.

Một dòng nhật ký hàng tháng hữu ích chứa gì

Một nhật ký chỉ nói ok không phải là một nhật ký đáng kể. Mỗi lần chạy nên ghi một dòng mà một người mệt mỏi có thể đọc trong mười giây: ngày, khối, trạng thái, tín dụng đã chi và số dư sau lệnh gọi.

Giả định: một dòng hiển thị khối bốn, trạng thái 200, một tín dụng đã chi và số dư còn lại sau lệnh gọi sẽ trả lời hầu hết các câu hỏi một tháng sau mà không cần mở phản hồi.

Các trường đáng để ghi lại

Ghi ngày, tên danh sách, số khối, mã trạng thái, tín dụng đã tính phí và số dư sau lệnh gọi. Sáu trường đó bao gồm hầu hết các câu hỏi một tháng sau.

Thêm ghi chú văn bản tự do chỉ khi một người đã thay đổi thứ gì đó bằng tay.

Cảnh báo không kêu sói

Cảnh báo ngay lập tức khi có mã 401 hoặc 402, vì cả hai đều có nghĩa là tác vụ không thể thực hiện công việc của nó. Cảnh báo số dư thấp nên sử dụng ngưỡng bạn đã chọn, vì vậy nó sẽ kích hoạt một lần và cho biết những gì cần làm tiếp theo.

Gửi một cảnh báo mỗi lần chạy, không phải một cảnh báo mỗi hàng, hoặc hộp thư đến sẽ trở thành nhiễu.

Ai sẽ nhận ra khi tác vụ bị hỏng

Một tác vụ hàng tháng chạy mà không ai giám sát nó. Đó là điểm của việc tự động hóa nó và cũng là lý do tại sao một lỗi có thể nằm không được chú ý trong nhiều tuần.

Chỉ định người đọc nhật ký và người sửa tác vụ. Hai tên tốt hơn một. Ngày lễ xảy ra. Sổ tay chạy giải thích cách chọn danh sách ngay từ đầu.

Thời gian dành cho thiết lập so với bảo trì

Lần chạy đầu tiên tốn phần lớn thời gian một giờ, vì khóa, bảng tính và lệnh gọi thử nghiệm đều cần sự chú ý. Sau đó, quy trình nên chỉ cần liếc nhìn mỗi tháng, không phải xây dựng lại.

Nếu việc bảo trì tăng lên, danh sách thường là nguyên nhân. Một danh sách thay đổi mỗi tuần cần một chủ sở hữu, một phiên bản và một quy tắc cho các bổ sung.

Làm cho lỗi có thể nhìn thấy

Một hàng bị thiếu trong đầu ra dễ thấy hơn một lỗi im lặng. So sánh số hàng với chiều dài của danh sách trong mỗi lần chạy và ghi cảnh báo khi chúng khác nhau.

Giữ cảnh báo đó trong cùng tệp nhật ký, để người đọc nhật ký thấy nó trước tiên.

Lên lịch xung quanh lần làm mới chỉ mục

Chỉ mục được làm mới khoảng một lần mỗi tháng, vì vậy việc chạy vào ngày đầu tiên của tháng có thể đọc các số từ bản xây dựng trước đó. Chạy sau vài ngày, như các bước trên đề xuất, cho phép làm mới thời gian để hạ cánh.

Chọn cùng một ngày mỗi tháng để chuỗi vẫn có thể so sánh được và viết ngày đó vào nhận xét trên dòng cron.

Khi nào ngừng tự động hóa

Một tác vụ chạy một lần mỗi quý có thể không đáng một dòng cron. Một bảng tính và lời nhắc lịch có thể là đủ và một quy trình bán tự động tệ hơn một quy trình thủ công rõ ràng.

Tự động hóa một khi các bước giống nhau đã chạy sạch sẽ trong nhiều chu kỳ liên tiếp.