「絶対要らないハズだけど、なかなか削除できずにいるもの」を対応した小話 | メルカリエンジニアリング
はじめましてこんにちは。SREの@masartzです。 私は最近joinしたのですが、今回は本番環境に古くからあるテーブルの掃除作業をした案件をご紹介します。 tl;dr; 本番の住所情報テーブルを消したけど問題なかった話 絶対要らないハズだけど、なかなか削除できずにいるもの を対処する話 本番環境の住所情報テーブルをdropするまでの作業 今回、本番環境の住所情報テーブルをdropしました。 と言っても、事故でもうっかりでもなく、既に使われていなかったものの整理という作業でした。 何故使われていなかったかというのは、メルカリの住所情報の保持の仕方の変遷が関係しています。 初期にはuser情報と住所情報は1対1の関係でした。イメージとしては以下です。 CREATE TABLE IF NOT EXISTS users ( id INT UNSIGNED NOT NULL, name VARC
チャットボットフレームワーク Ruboty を振り返る - r7kamura - Medium
Ruboty を利用したデプロイの様子この記事では、Slack や HipChat で動く Bot をつくるためのフレームワーク Ruboty の仕組みを振り返り、現状の実現方法を把握し、今後 ChatOps を改善するための足掛かりとしたい。 出勤、デプロイRuboty というチャットボットフレームワークを数年前から開発しており、仕事でも Ruboty でつくった Bot を使った業務フローを導入・運用する機会が増えてきた。例えば、いま働いている会社では、Qiitan という Bot が出勤管理やデプロイに使われている。 Qiitan に最もよく投げかけられている発言は、「@qiitan 出勤」である。この発言を行うことで、自動的に社で利用している出勤管理サービスに対して、発言者が出勤した旨を代わりに登録してくれる。他によく使われる発言として「@qiitan デプロイしたい」がある。これ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
