Kiểm tra backlink miễn phí trước, sau đó chi $100 có mục đích

Ba ngân sách, tất cả đều là giả định

Đây là các ví dụ lập kế hoạch, không phải báo cáo từ tài khoản thực. Thay đổi khối lượng và phép tính vẫn giữ nguyên, vì vậy hãy thay thế bằng dữ liệu của riêng bạn.

Ngân sách A, một widget công khai

Một công cụ kiểm tra DR miễn phí trên blog của bạn sử dụng domain, tốn 0 credit. Mười nghìn lần tra cứu mỗi tháng đều miễn phí ở API, và hóa đơn duy nhất bạn phải trả là chi phí lưu trữ, không liên quan đến chúng tôi. Một công cụ kiểm tra backlink miễn phí trên blog cũng là cùng một lệnh gọi, được thực hiện từ một trang mà khách truy cập có thể thấy.

Lưu cache các lệnh gọi miễn phí trong một ngày, theo cách hướng dẫn Next.js làm. Một widget nhận được một nghìn lần tra cứu từ một bài viết phổ biến rồi thực hiện một lệnh gọi upstream mỗi domain mỗi ngày, giúp phép tính ngắn gọn và trang web tải nhanh.

Hóa đơn quan trọng nhất cho một widget là chi phí lưu trữ và xử lý lưu lượng, vì vậy hãy định giá những thứ đó trước và coi API là mục nhỏ mà nó vốn có.

Ngân sách B, báo cáo agency

Hàng tháng, 300 domain khách hàng, mỗi domain một lệnh gọi refdomains với giá 2 credit. Đó là 600 credit mỗi tháng và 7.200 credit mỗi năm, tương đương $0,72. Con số nhỏ. Số dư $100 sẽ chi trả khoảng 139 năm ở mức đó, vì vậy lưu trữ và thời gian của chính bạn mới là yếu tố chi phối, không phải API.

Lịch trình là đòn bẩy ở đây. Chạy cùng 300 domain hàng tuần thay vì hàng tháng nghĩa là tăng gấp bốn lần số lần chạy, và vì chỉ mục được cập nhật khoảng mỗi tháng, hầu hết các kết quả hàng tuần sẽ lặp lại kết quả trước đó.

Ngân sách C, một bản xuất đầy đủ

Một domain, 50 lệnh gọi với 1.000 dòng để đạt giới hạn 50.000, với giá 2 credit mỗi lệnh gọi: 100 credit, tương đương một xu. Lặp lại cho 1.000 domain và bạn sẽ chi 100.000 credit, tương đương $10 trong số $100 và một phần mười số dư.

Chi phí credit là nhỏ, nhưng số dòng lưu trữ thì không. Hãy lập kế hoạch dung lượng đĩa cho chúng tương tự như cách bạn lập kế hoạch cho credit, và chỉ giữ lại các cột mà báo cáo của bạn cần đọc.

Nếu bản xuất phải được lặp lại mỗi tháng, con số hàng tháng mới là thứ bạn nên đưa vào ngân sách, không phải tổng số một lần.

Những gì ngân sách chưa bao gồm

Lưu ý những gì đang thiếu: một kế hoạch hàng tháng. Không có đăng ký cần gia hạn, và bạn trả tiền cho các lệnh gọi, không phải cho số lượng người dùng. Rẻ. Mọi ngân sách đều dựa trên cùng một sự thật. Kịch bản bulk và ghi chú về phân trang cho thấy mã nguồn đằng sau các số lượng lệnh gọi đó.

Một ngân sách bỏ qua yếu tố thời gian là chưa đầy đủ, vì vậy phần tiếp theo sẽ bổ sung các chi phí nằm ngoài danh sách giá.

Một dòng nữa thuộc về mọi ngân sách: chi phí chạy lại một công việc bị lỗi. Nếu một lần chạy dừng lại và bắt đầu lại từ đầu, các lệnh gọi đã trả phí sẽ được lặp lại, vì vậy logic tiếp tục là một mục ngân sách.

Những gì ngân sách không bao gồm

Dòng API là mục nhỏ nhất trong hầu hết các dự án. Ba chi phí khác thường quan trọng hơn, và một trang ngân sách nên nêu rõ chúng.

Lưu trữ và lưu trữ dữ liệu

Máy chủ, cơ sở dữ liệu và máy chủ cron của bạn sẽ được tính phí riêng, và tổng chi phí có thể cao hơn cả các lệnh gọi. Hãy tưởng tượng một công việc chạy vào ban đêm trên một VPS nhỏ: VPS mới là dòng chi phí cần theo dõi, không phải các lệnh gọi.

Một bảng thô chứa các phản hồi đã lưu trữ cũng chiếm dung lượng đĩa. Hãy ước tính sự tăng trưởng của nó từ một lô được lưu, nhân với số lần chạy bạn dự định.

Định giá công việc trước khi chọn nhà cung cấp. Một công việc cron chạy một lần mỗi tháng cần ít tài nguyên hơn nhiều so với một worker chạy liên tục cả ngày, và sự khác biệt này thường quyết định ngân sách.

Log cũng là một chi phí. Một dòng mỗi lệnh gọi, được giữ trong một năm, sẽ tích lũy nhanh trên một công việc bận rộn, vì vậy hãy quyết định thời gian lưu giữ một cách có chủ đích thay vì mặc định.

Chuyển đổi sau hai năm

Lập ngân sách cho việc rời đi, không chỉ cho việc bắt đầu. Nếu một bản thiết kế lại hoặc một nhà cung cấp mới xuất hiện sau hai năm, công việc chính là lớp fetch và ánh xạ trường, và kịch bản bulk sẽ giữ lại các body thô giúp việc ánh xạ đó dễ dàng hơn.

Giữ các phản hồi cũ trong thời gian lịch sử còn quan trọng với bạn, vì chúng là hồ sơ duy nhất về các con số mà báo cáo của bạn đã sử dụng.

Việc ghi lại kế hoạch rời đi hiện tại tốn một giờ. Việc phát hiện ra sau hai năm rằng các body thô chưa từng được lưu sẽ tốn kém hơn nhiều khi phải xây dựng lại lịch sử.

Lưu một mô tả ngắn gọn về từng trường bạn đọc, trong cùng thư mục với các body thô. Mô tả đó là thứ cho phép một nhóm tương lai ánh xạ lịch sử mà không cần đoán mò.

Thời gian của chính bạn trên lớp fetch

Lớp fetch, các lần thử lại và danh sách cho phép tốn một buổi chiều để viết và lâu hơn để kiểm thử. Hãy tính toán thời gian đó trước khi quyết định một công cụ miễn phí là miễn phí.

Đây là dòng chi phí mà hầu hết các ngân sách bỏ qua, và thường là mục lớn nhất sau chi phí lưu trữ. Hãy ghi nó ra, để việc so sánh được công bằng.

Một bài kiểm tra tốt là thời gian cần thiết để một developer mới thực hiện một lệnh gọi từ đầu. Nếu việc đó tốn một ngày, lớp fetch mới là chi phí thực sự của dự án, không phải credit.

Đặt một con số ước tính theo giờ bên cạnh thời gian đó, ngay cả khi chỉ là phỏng đoán. Một phỏng đoán được ghi lại sẽ dễ bị thách thức hơn một chi phí không bao giờ xuất hiện trong bảng tính.

Kiểm tra phép tính trước khi tin tưởng nó

Một ngân sách chỉ tốt bằng phép nhân của nó. Hai bước kiểm tra sẽ bắt được hầu hết các lỗi trước khi một lần chạy theo lịch trình diễn ra.

Bắt đầu từ giá mỗi credit

Một credit là $0,0001. Điều đó có nghĩa là 10.000 credit là $1 và toàn bộ 1.000.000 credit khởi đầu là $100, đây là phép chuyển đổi duy nhất cần thiết cho bảng kế hoạch.

Viết phép chuyển đổi một lần, trong một ô hoặc một hằng số, và tái sử dụng nó. Nhập lại nó ở ba nơi là nguyên nhân khiến bảng tính có ba mức giá khác nhau.

Giữ bảng tính ở đơn vị credit cho đến dòng cuối cùng. Chuyển đổi sớm rồi nhân lại là nơi thường xảy ra lỗi nhân thêm một hệ số mười mà không ai nhận ra.

Một bảng tính có cột tiền tệ dễ dẫn đến làm tròn số. Hãy giữ một cột credit bên cạnh cột đô la, và để số đô la là kết quả suy ra.

Kiểm tra một lệnh gọi với số dư

Thực hiện một lệnh gọi trả phí, đọc _credits trước và sau, và kiểm tra xem sự sụt giảm có bằng giá của hành động đó không. Một lệnh gọi refdomains nên làm thay đổi số dư 2 credit, và một lệnh gọi search là 3 credit.

Nếu sự sụt giảm khác biệt, hãy dừng lại trước khi một lần chạy theo lịch trình khuếch đại sự sai lệch đó. Lệnh gọi kiểm tra tốn vài phần nghìn xu, khiến nó trở thành phép kiểm tra rẻ nhất trong toàn bộ ngân sách.

Ghi lại phép kiểm tra trong cùng log với các lần chạy. Một tháng sau, dòng kiểm tra sẽ cho biết chi phí của mỗi hành động khi bảng tính được viết, điều này hữu ích nếu danh sách giá thay đổi.

Kiểm tra số dư trên trang tài khoản của riêng bạn một lần. Hai con số phải khớp nhau, và sự không khớp đáng để ghi lại một ghi chú ngắn trong sổ tay chạy (runbook).