取得処理は増える一方です。新しい分析のたびに1つ増え、要らなくなっても消えません。使わなくなった分析のための取得が、毎日静かに動き続けます。
止めないことの費用は目に見えません。相手のサーバを叩き続け、保存先を消費し、仕様変更のたびに直す対象になります。動いている限り誰も文句を言わないので、放置されます。
この回では、止める判断をどう下すかを扱います。増やすより難しいのは、止めて困る人がいないことを証明できないからです。
使われているかを測る
まず、取得したデータが読まれているかを見ます。取得の回数ではなく、保存先が読まれた形跡です。読まれていないなら、少なくとも自動処理からは使われていません。
人が手元で読んでいる場合は記録に残りません。そこは EP.38 の一覧にある「誰のため」の欄で補います。記録と一覧の両方が空なら、止める候補として扱えます。
| 読まれた形跡 | 一覧の用途欄 | 判断 |
|---|---|---|
| あり | 記載あり | 続ける |
| あり | 空欄 | 使われている。用途を追記する |
| なし | 記載あり | 記載が古い可能性。確認する |
| なし | 空欄 | 止める候補 |
使われているかどうかは、感覚ではなく記録で見ます。の呼び出し回数ではなく、保存した結果が読まれたかどうかです。読まれた形跡は、保存先の種類によって取り方が違います。ファイルなら最終アクセス時刻、データベースなら問い合わせの記録。をファイルとして置いているなら、読み込みの記録を自分で残す必要があるかもしれません。
に登録されているのに、参照している処理が見当たらない。こういう取得がいくつか見つかるはずです。動いていること自体が、必要である証拠にはなりません。
from datetime import date, timedelta
def find_candidates(jobs, last_read: dict[str, date], unused_days: int = 180) -> list[str]: """一定期間読まれておらず、用途も記録されていない取得を返す。
どちらか片方だけでは判断しない。人が手元で読んでいる場合は 記録に残らないので、一覧の用途欄と合わせて見る。 """ threshold = date.today() - timedelta(days=unused_days) out = [] for job in jobs: read_at = last_read.get(job.name) never_read = read_at is None or read_at < threshold if never_read and job.is_orphan(): out.append(job.name) return outいきなり消さない
止める候補が見つかっても、いきなり削除してはいけません。四半期に一度しか使わないデータかもしれません。年度末にだけ参照されるものもあります。
段階を踏みます。まず取得を止めて、保存先は残す。しばらく様子を見て、誰も困らなければ保存先も片付ける。この間に「あのデータが更新されていない」と言われたら、戻せばよい。
from dataclasses import dataclassfrom datetime import date
@dataclassclass Retirement: """段階的に止める。いきなり消さない。"""
job: str announced_on: date # 止めると伝えた日 stop_fetch_on: date # 取得を止める日 delete_data_on: date # 保存先を片付ける日
def stage(self, today: date) -> str: if today < self.stop_fetch_on: return "予告中（まだ動いている）" if today < self.delete_data_on: return "取得停止済み・データは残っている（戻せる）" return "片付け済み"
def check(self) -> None: if self.stop_fetch_on <= self.announced_on: raise ValueError("予告なしに止めることになっている") if (self.delete_data_on - self.stop_fetch_on).days < 90: raise ValueError("停止から削除までが短すぎる。四半期の利用を拾えない")止めた取得の記録を消してしまうと、半年後に同じものをまた作ります。「いつ、なぜ止めたか」を残しておけば、再び必要になったときに、当時の理由を踏まえて判断できます。
戻せる状態を保つことも大事です。取得を止めてもに過去のデータが残っていれば、再開したときに欠けるのはその期間だけで済みます。の口が生きていれば、遡って埋め直すこともできます。
止めるときは、cronの設定を消すのではなく無効にするほうが安全です。設定そのものが残っていれば、戻すのが一瞬で済みます。消すのは、戻さないと確信できてからで構いません。
止めやすくしておく
そもそも止めやすい作りにしておくと、この作業が軽くなります。1つの取得が1つの単位として完結しているなら、止めるのは設定を1行消すだけです。逆に、複数の取得が絡み合っていると、止められません。
保存先も分けておいてください。1つの場所に複数の取得が書き込んでいると、どれを止めるとどのデータが消えるのかが分かりません。EP.05 で扱った配信元ごとの分離が、ここで効いてきます。
止める作業に目に見える成果はありません。それでも、放っておくと必ず溜まる種類の負債です。定期的に見る時間を確保しておくのが、結局いちばん安く済みます。
止める判断は、増やす判断より慎重になりがちです。止めて困る人が出るかもしれない、という不安があるからです。だからこそ、段階を踏んで戻せる形にしておくことに意味があります。
取得を止めた後も、しばらくは問い合わせが来ないかを気にしておいてください。誰も何も言わない期間が続いて、はじめて本当に不要だったと分かります。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。