👋

エンジニアの手動運用の業務改善はいつやる?

2022/01/22に公開約4,300字

すべての運用が自動化されている会社などありません。ここでいう運用とは何かというとサービスを提供する上で定期的に実行しなければ行けないものだったり、自動化や管理画面の作成が間に合わずに人の手で順番の制御やSQLを実行したりする作業です。他にもいろんな運用はあるのですが(むしろソッチのほうが多いかもしれません)が、ここでは時間があったら改善できるものに絞って話を勧めていきます。

管理画面の実装が間に合わない場合

BtoBtoCの会社などでアジャイル開発をしている会社などによくあるのですが、管理画面を作り切る前に入稿データをGoogleFormなどで情報をもらってそれをSQLにして登録してユーザーに提供するパターンなどがあります。

toBとtoCとで両方の顔立てる必要がある場合の構図としてはこちらになります。

toBには情報を入力してもらうという手間をかける分、それがユーザーに刺さらないのであれば対応しただけ無題になってしまいます。なので、縮小版で特定の会員にのみに機能を開放などしてそこでベータ版として検証すると言う構図出来上がっていきます。

社内向けの機能は特に効率化されない。

上記のようなSQLを定期的に書いて実行するような作業はあとで管理画面を作る前提のものが多いと思います。toB側に入稿してもらって、toC向けにこうかいするものであれば本稼働するときに必ず作り込まれるので心配がいりません。

ただ、社内システムの場合は特に運用の効率化などがされずに一旦スプレッドシートでいいか、手順としてドキュメントにまとめたからいいかみたいなので全然効率化されないパターンがあります。

具体的な機能例として上げると、

  • 会社独自で開発したABテストの機能
  • なにかユーザーやクライアントにお知らせを表示するような機能
  • システムにするかどうか迷う頻度で来るイレギュラーな運用

こういったものはその場しのぎだったり、システムにしなくてもサービスがやっていけるなと判断されて自動化されないでいることが結構あります。

なぜなら、その自動化に取り掛かる工数というのはどこにも確保されていないからです。

山積みになったタスクを抱えて、短期的にはお金にならない効率化のところを解消する機会が与えられることは少ないです。

手動運用の改善はするべきか?

するべきです。絶対にするべきです。システム化されていない運用というのは、ただ単に作業担当者の時間を消費するだけではありません。

まずは運用を引き継がなければいけないですよね。ずっと同じチームで同じプロダクトを触っていけるということはありませんので、次の担当者に歴史的な背景や手順を正確に伝える必要があります。似たようなところを触るとき、ソースとして残っていないので他の人が手を加えたときに障害になりがちです。作業担当者のモチベーションも下げがちです。特に忙しいときに、変な運用が発生して、それの修正をしなければいけないのは苦痛です。

手動の運用は使う時間以上に作業者に負担を強いることをしっかり理解しましょう。

どのように運用の自動化やシステム化を行うのか

説得フェーズ

基本的には時間をとるということに尽きると思います。

まずは時間の算出から始めましょう。その運用に一年でどれくらい時間を使うのかを考えましょう。単純に運用にかかる時間を算出してみましょう。

時間の算出が終わったら、コミュニケーションのためにかかる時間やタスクのスイッチングコストとまで考えてもいいと思います。

それらを持って、システム化にかかる時間を算出してプロジェクトの取りまとめに直談判するのが良いでしょう。費用対効果が良ければそれを妨げることはないと思うのでそこはプロとして譲歩せずに説得しましょう。

アジャイルでシステムの運用改善に取り組む

最近はアジャイルで、特にスクラムでシステムの開発に取り組むチームが増えてきました。ここでは、スクラムがいいかどうかという話はしませんが、触りだけスクラムでは開発サイクルを細かく切って開発を進めていきます。

機能単位というよりは、期間で区切って開発します。その区切りをスプリントと言うのですが、例えば、そのスプリントの中で20%の工数を負債の解消に費やすとします。ということは開発に使える工数の20%は自動化や保守メンテの向上に使えるので、手動運用なども減っていくかのように思えます。

ただ、こちらを勧めていった場合にそのタイミングによっては落とし穴があります。20%の運用改善や負債解消の工数をスプリントの後ろで実施した場合に起こりがちです。20%ルールを適応する必要があるチームと言うのは、プロダクトにそれなりに負債を抱えている場合も多く、見積もりと進捗がずれて工数が足りなくなりがちです。そういった場合に、機能開発のバッファとして使用されることがよくあります。

なので、解決法としては、20%ルールは強い意志でスプリントの前半にこなすことをおすすめします。当然これは、チームとしての方針として定めてもらってやっていただくのが一番良いと思います。

運用改善しやすいアーキテクチャを作る

システムは何かをトリガーにして起動します。それはHttpリクエストであったり、スケジューリングされたプログラムの起動かもしれません。それとは別に、「注文された」、「発送を開始した」のようなビジネス的なイベントかもしれません。定期実行するというのは、簡単で扱いやすい反面で整合性を取るのが非常に難しいシステムだと思っています。

つまるところ何が言いたいかというと複数の定期実行するサービス感でうまく整合性を取るのが難しいと思っています。

例えば、夜10時に実行されるプログラムAとその後に実行されるべきプログラムBがあるとします。Aの開始の後にBは実行しなければいけないけれど、Aはいつ終わるのかというタイミングの連携がわからなければサービスが成長することでデータが多くなっていくことで少しずつ時間がかかるようになるかもしれません。もしくは、何かしらの機能を追加したことで、Aが不具合を起こしてしまったとします。そしてBは、Aに依存していますがその結果を知ることができないので、通常通りに実行されてしまいます。

時間実行で成功する前提で、システムを組むともし何かしらの不具合が起きたときに非常にもろくなってしまいます。加えてだいたいそういう不具合が起こるのって忙しい時期だったりします。(繁忙期でアクセスがピークになったりなどいろんな不具合や機能開発のピークを迎えた時期だったりします)

ここのプログラムの実行のどこに問題があるのでしょうか?整理してみましょう。

  • プログラムAの後にプログラムBが実行されるということに確実性がない
  • プログラムAの失敗の後に、システム(データ)が想定される状態になっているのかの保証がない

そういうときに応用できる手法がいくつかあります。本当にしっかりするシステムを作るのであれば、結果整合性を保った実装の方法があります。

結果整合性を取るというのは、複数書き込み処理をするプログラムがある場合にそのシステムの一部がエラーになったとき、そこで実行の中断をやめて複数システムのロールバック(システムに正しい状態まで戻す)というような仕組みです。

実装パターンとして、探す場合にはSaga(長期プロセス)について探すのがいいでしょう。用途に合わせて2つのパターンがありますので検討してください。

  • コレオグラフィーサーガ
  • オーケストレーションサーガ

個人的なおすすめとしては、データベースに何かしらのフラグなどを保つ必要などはありますが、コレオグラフィーサーガのほうがシステム的に疎結合になりやすいのでおすすめです。

システムを構築する上で重要になるのは時間実行するしか選択肢がない状態にしないことも重要です。何をしたらよいかというとイベントバスを入れることで、選択肢を増やすことだと思います。イベントバスとは、イベントを受け取ったり、そのイベントを受け取ったときにプログラムを実行できるような仕組みのことです。要件としては、イベントの順序が保証されていること、発火したイベントによって一つ以上のプログラムが実行可能なことです。

具体的なものを上げると、Apache Kafkaなどでイベントの受け取りとサブスクライバーの実行などができるようにしておくのも良いでしょう。KafkaはOSSで開発されているので自前でデプロイしてメンテナンスをしてもいいですし、AWSをつかっていたらManaged Service For Kafkaなどもあるのでそちらを利用するのが良いでしょう。そうでなければ、FIFO SQSとFIFOのSNSを連携されてKafkaを代替するのが少々運用コストは増えると思いますが、小さく始めやすいと思います。FIFOを使うのはイベントの順序を保証させるためです。

手動運用を改善しやすい環境

手動運用を解消するのにフルスクラッチは、どうしても時間を取れない場合。そういった場合の強い味方となるのは、スプレッドシートだったりします。この場合は、ロジックがスプレッドシートに入ってしまったりするので、メリットは単純に手動運用で行っていた時間を削るだけです。ケースバイケースで、どのような手法がいいのか各々で判断してもらうしかありません。

SpreadSheetに異なるシステムから書き込みをするときは、APIキーなどGoogle Cloud Platformのプロジェクトが必要になるので早めの段階から調整してプロジェクトだけでもあると非常に勧めやすいです。

後々いろいろ考えてきて、CleanArchitectureで作られているAPI開発が自動化を妨げていることに気づいて、APIを作らないという選択肢を考えはじめました。結果的にhasuraを入れていまはガンガン手動運用を撲滅していっています。

まとめ

手動運用などは改善するに限るのですが、そういった場合にもシステムの正しい構築の仕方などを知らないと新しく負債を作るだけだったりします。また、選択肢を予め用意しておかないと、負債解消もうまくすすまないことがあるので常日頃からどうするべきかについて思考を巡らせて、準備をすすめると良いでしょう。

Discussion

ログインするとコメントできます