スリーシェイクのSREの堤です。

本日は、「SREとシステム運用」に関して、15年以上のエンジニアで培ってきた経験を元に、私自身のシステム運用に関する考えを述べていきたいと思う。

※この記事は、株式会社スリーシェイクとしての考えを代弁するものではなく、あくまで一人のエンジニアとしての考えです。

はじめに

私は大阪で15年以上、ITエンジニアとしてキャリアを積んできた。

技術的な分野は、インフラ、ソフトウェア開発、セキュリティ、クラウドなど多岐に渡る。そして15年間のキャリアの前半は製品を売る立場、そして後半、製品を運用して活用する立場であった。

その15年間において、私がシステムにおいてとても大切にしているのは、「運用」だと考えている。いくら高機能で素晴らしい製品であっても、運用のしづらい製品であればそれは宝の持ち腐れだ。

特にセキュリティ製品は、いかに「運用」ができることが重要視される。導入して放置だと全く意味がなく、導入後の定義ファイルの更新、ファームウェアの更新、そしてアラート/インシデント管理いったことが必要だ。これはセキュリティ製品に限った話ではなく、ERP、メールサーバ、クラウドインフラ、そして業務アプリケーションにも言えることだろう。また、会社の経営も、そして人生そのものも一種の運用だと思う。

ベンダーの立場、運用者の立場

私のキャリアの前半は大手ネットワークインテグレーターにておよそ8年間、IDS/IPS、メールセキュリティ、ウイルス対策、SIEM、認証基盤を顧客に提案して導入までをメインに担当していた。

その後はもちろん製品に関する問い合わせ（設定の仕方、製品トラブル対応、ライセンス期限切れ対応など）には対応はしていた。しかし、顧客がどのようにサーバー、ネットワークの資産を抱えて、どのように運用しているかに関しては、正直なところそこまで深くは理解できておらず、想像の中で対応していたのはしばしば。

しかし、月日が流れていくと日に日に「ITインフラはどのように運用されているのだろうか」「運用を知らないのでは、ITエンジニアとしてまずいのでは？？」と思い、8年近く勤めたネットワークインテグレーターを退職。その後、自動車メーカーの社内SEや、SI企業のデータセンター部門での社内システム開発、スタートアップでのSaaS基盤の管理と改善などなど・・・そして新規開発など数社転々とし、システムを活用して運用する立場として経験を積んでいく。

両方の立場に立ってITエンジニアとして経験を積んだ結果、いろいろな気付きと学びを得ることが出来た。この点に関して、まとめていきたいと思う。

Automation: 運用を自動化していく

まず運用をできる限り自動化していく。およそ10年ぐらい前までは、「手順書」や「パラメーターシート」をWordやExcelなどに落とし込んで、管理していた。

しかし、手順書やパラーメーターシート等、人間の手が介在すると、一定の確率で作業ミスや更新漏れ、などのヒューマンエラーが発生する。人間は、一定のパフォーマンスを維持するのは難しい。

いくら体力自慢の方でもずっと仕事をしているとパフォーマンスを低下する（もちろん、筋力トレーニングやランニングなどの日常的なエクササイズは推奨される）。また、仕事やプライベートでの心配事などの心理的な部分でモチベーションやパフォーマンスも低下することもしばしばある。ということで、システムにおいて人間の性能に頼るのは少々危険だると言えよう。

近頃はInfrastructure as Code、DevOps、GitOpsなど多数のモダンなシステム設計、運用の考え方が存在する。数年前から、ITインフラストラクチャの世界ではメインストリームになっているが、Infrastructure as Codeは重要だと思う。インフラの定義をコードに落とし込む考え方。これは、Dockerfileであったり、AnsibleのPlaybookであったり、Kubernetesのマニフェストファイルに相当するであろう。

これは自動車の運転に例えるとわかりやすい。人間による運転と、自動運転。人間の運転の場合、手でハンドルを握って、足でアクセルとブレーキを匠に操って目的地まで移動する。対する自動運転は、目的地さえ決めたらあとは自動車が連れてくれる（※現在の自動運転技術の場合、法的な問題もありまだ実用段階にはないが、それはいずれ時間が解決されるであろう）

そして、既製品の範囲では解決出来ないことは、自らコーディングをしていく。当社はGolangやPythonを使うことが多い。これをLambdaやCloud Fuctionのサーバーレスで実現したり、もしくはコンテナ化してCloud RunやFargate、もしくはKubernestクラスタに展開する。

データ連携の場合はETLを用いて行うと良いだろう。ETLでは、当社ではReckoner（レコナー）というSaaS型ETLサービスを提供しているためこちらも合わせてご確認いください。

https://reckoner.io/

Monitoring: 可視化していく

そして、システムが正常に稼働しているどうかを確認するためには、可視化していく必要がある。これは、バラバラで稼働しているシステムから出力されるログ、メトリックスなどに基づいて、人間が理解できるような形に意味づけするための過程である。量子力学に例えると、存在しないもの（波動性）を、存在するもの（粒子性）にするになるだろう。

このMonitoringに関しては、いろんな考えや種類が存在するだろうが、代表的なものは以下の4つだと私は思う。

• メトリックス（サーバ/ネットワーク監視）
• アラート通知（メール、Slack、PagerDutyなど）
• インシデント管理（システム障害、セキュリティインシデントなど）
• ログ統合管理（SIEM）

いずれも人間が認知できる形で表現される。その時点のデータ（スナップショット）だけでなく、過去から現在にかけての時系列データに基づいてグラフで表現したり、場合によっては深層学習による予知までもできるようになるだろう。

また、バラバラで独立したシステムから出力されるログをSIEMなどに分析をかけることで、相関的にインシデントを検出することも可能だ。これは、SSHへの複数のサーバへの偵察行為に役立つ。サーバー単体でのログに限定して分析すると数回程度の偵察行為であるだろう。しかし、サイト全体に数百台サーバの存在する場合、大規模な偵察攻撃と検出することができる。

Agile: 速く失敗して速く改善する

そして、改善。システム運用は一度で完璧に組めることは無いだろうし、おそらくそれに終わりはない。常に改善し続ける必要がある。

正直なところ実際に、デプロイや運用してみないと分からない事の方が圧倒的に多い。現在はシステムがどんどん複雑化してきているので、どんどん機能改善してデプロイし、そしてたくさんの気付きを得る。もちろん、やってみて失敗することも出てくるだろう。しかし、その失敗から学ばないと何も前に進むことができない。

これは中国の大昔の思想家である孔子も、論語のなかで同じようなことを言っている。

孔子曰く：
「過まって改めざる、是れを過まちと謂う（过而不改，是谓过矣）」

現代日本語訳にすると「過ち（失敗）を改めなければ、それこそが過ち（失敗）である」ということになる。もちろん、大規模な障害やセキュリティインシデントにつながるような失敗は避けるべきだが、想定外の小さなエラーなどはどうしても出てくるであろう。

そしてこれで得た気付きを、上の画像のような付箋で管理するのもよしだろうし、RedmineやJiraなどのチケットトラッキングシステムを使って管理するのもありだろう。そして、この改善をしっかり責任の所在をはっきりさせて、前に進めていくことが重要だ。

Absorb：最新の技術トレンドのキャッチアップ

最新技術のキャッチアップも重要だ。

これはベンダー側に居た人間だからこそ、現在どのようなプロダクト/ソリューションがあり、そしてどのような商流で購入できるのか手に取るようにわかる。ベンダーとの付き合い方も熟知しているので、いい情報の引き出しかたも理解している。

あとは、勉強会への出席。近頃はオンラインでの開催が非常に増えてきており、気軽に参加できるようになったと感じている。ただ、本当はFace to Faceで会って友人になってネットワーク構築するほうが好きなんだが。。。勉強会のいいところは、現場のエンジニアの声や意見が聞けることだ。これは実際の本番環境でデプロイした生の経験が聞ける絶好の機会だったりするので、定期的に参加することをオススメする。

また、機会があれば、自ら発表するのもいいだろう。プレゼンテーション能力が向上、自分や所属企業のアピールにも繋がる。

スリーシェイクのSREとは・・・

実際書いてみると長い文章になった。もちろん、ここに書いてあることは自分の中の「システム運用」に関しての考えの一部であり、アウトライン的な要素が多い。

システム運用の最適化は、環境ごとに異なってくる。そのため、現場で肌で感じながら運用していくことが重要だと感じている。何が一番重要だろうか、一つの単語で表すと「気付き」じゃないかと思う。この気付きに関しては、システム運用の現場でないとなかなか感じ取ることができない。受託開発して引き渡して終わりだとなかなかこれは難しい。

当社スリーシェイクのSREたちは、ベンダーである立場でもあるが、運用者の立場でもある。決して客先常駐しているのではなく、一緒にシステム運用の現場を感じながら、顧客と日々システムを改善しながら突き進むのである。今後の日本でのDXのベンチマークになるのではないかと感じている。

スリーシェイクでは、インフラエンジニア、開発者、プロジェクトマネージャなどのエンジニアを随時募集しております。気になった方は、ぜひ一度カジュアル面談でも。

https://www.wantedly.com/companies/3-shake