株式会社開発本部の佐藤です。月もそろそろ終わりですね。スポンサー枠で登壇しましたので、発表準備の過程で考えていたこと・発表後に改めて思い返したことを書きます。発表時の資料はこちらになります。当日は「クラウド基盤×自作EPCによるフルMVNOの運用とその実態」というタイトルで発表しました。システムの開発初期を支えたメンバーが徐々に離脱するなか、知識・経験が不足している自分が何に悩み、どんな道筋を立てて運用を引き継いだかを伝えたいと思いました。以下ではその中身を述べていきます。出向してすぐに「さくらのセキュアモバイルコネクト」のモバイルコア部分の運用開発メンバーに加わりました。参加して間もない頃に発生した通信障害の対応を通してモバイルシステム特有の運用の難しさを実感しました。何らかのトラブルにより通信断が継続した場合にはシグナリングストームが発生すること外的要因(基地局〜モバイルコア間のネットワークのどこかで発生する通信断など)が解消された後でもシグナリングストームによる大量の通信要求を処理しきれないケースがあることまた、フルスクラッチで内製されたシステムであるため運用担当者には以下の認識が必要と感じました。業務および前職のシステム管理業務では、不具合発生時には予め定められた作業手順書に従って対応すること、復旧が困難な場合にはサポート先へエスカレーションすることが原則だったため、自分がこの水準を満たすには相応の時間が必要と判断しました。何ヶ月か経過した後、開発初期からこのシステムを担当しているメンバーが社内異動等により徐々にチームから離れていくことが決定していきました。自分が主担当として運用していくために何をすべきか初期メンバーがチームを離脱するまでにある程度の期間が設けられていたため気持ちの準備はできていたものの、各メンバーが通常の業務に追われる日々が続いたため引き継ぎのための時間を十分に確保することは困難な状況でした。そのため、開発初期メンバーと同等の知識経験が無い自分がこれまで実現されていた運用水準を維持向上してくためにはある程度の方針・計画を立てて進めていく必要があると感じました。それをふまえて実践したことが以下になります。認識の共有ができるための準備システムを構成するサーバ・ルータの詳細なネットワーク図を作成しました。意識した点として障害箇所とその影響箇所がひと目でわかるよう、すべての構成要素が一枚の図に納まるようにしました。アドレスの明記を必須としました。開発初期のメンバーといっしょに進めてきたミドルウェアの統合化作業をメンバー離脱後も継続しました。多少の修正を加えれば必要が無くなるミドルウェアは基本外す方向で積極的に置き換えていき、システム全体の構成をシンプルにすることに努め、障害発生時に疑うべき点を減らしていきました。自動デプロイの導入はあえて採用しなかった自動デプロイの導入が当初より検討されていましたが、理解が必要な技術が増えること、中途半端な状態で導入した場合の運用リスク(障害発生時、デプロイツールの動作に問題が無かったかを検討する時間が発生するなど)を懸念し、枯れた手段であるコマンドが列挙された手順書によるメンテナンス作業をあえて採用するようにしました。サービス提供主体側との密な連携サービス提供主体であるさくらインターネット側のメンバーと役割分担を推進して通信障害が発生した際に原因究明に注力できる体制を設けました。障害対応後の振り返りができるよう各役割の連携フローをまとめ、実際に障害が発生した際に用意したフローに従ってお互いが連携できるよう合同の運用訓練を定期開催するようにしました。稼働率(通信断の状態だった時間の合計割合)が前年度比で改善できたことは素直に嬉しかったです。これまでのメンバーと行ってきた運用のあり方を変えていくことには正直不安がありました。開発初期メンバーが継続して運用する体制が維持されていれば、より良い体制になっていたのではないか?と常に感じていたためです。今回の経験を通して自分が主担当として運用するシステムは自信を持って運用できる体制に思い切って切り替えていくことは、システムを引き継ぐ上での有効な手段であると強く感じました。現在の取り組み初期の頃を不安を乗り越えてたくさんの知識と経験を得ることができました。ソースコードの修正も抵抗なく行えるようになりました。環境の構築に挑戦しています。システムの更なる安定化と改善頻度の向上が両立できるよう精進していきたいと思います。Networksの佐々木です。(1)はてなブログをはじめよう!bbsakuranetさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。