taso0505

## 概要 * インターネット広告配信システムのDevOps ## 規模 * 4名（自社4名、協力会社0名） ## 役職 * グループマネージャー ## 担当 * 商用システムのインフラ運営（企画〜運用）およびDevOps推進と情報セキュリティ対策推進 * インフラ部門の組織開発・育成 ## 環境 * 自社 ## 課題 1. 過去のインシデントに対するアプローチや対策が人の頭の中に存在していることで、ナレッジが継承されて行かず、運用の再現性がない。 2. ansibleで一部の構築/運用をしているが、手作業が多い。また、ドキュメントがなく、他のメンバが利用できない状況。 3. 上場企業の内部/外部監査に耐えうるセキュリティになっていない。 ## 成果 1. 過去の作業をRedmine、slack、JIRAから抽出し、インシデント対応の手順をリバースエンジニアリングした。（自動化できるものはplaybook化した） ドキュメントはエンジニアが読みやすいようにMarkdownで作成。 今後の作業をJIRAで管理し、JIRAで作業管理、インシデント管理、課題管理などプロジェクトを回すうえで必要な統合管理基盤をITIL、スクラムマスターの知見を活用しつつ、構築した。 また、対応したタスクや手順はナレッジDBとして、Githubに蓄積し、チームメンバ以外からも参照可能にすることで、自チーム以外でも利活用できるようにした。（フィードバックをもらうことで、より良いものへブラッシュアップしていく） 結果として、`JIRAによるプロジェクト管理、「15h/月」の工数削減、200件以上のナレッジDB構築`を実現した。 上記に加えて、`DevOps / CSIRTの組織を1から立ち上げ、運営する事で関係者とのシナジーを創出（20h/月の工数削減）する事に成功`した。 2. ansibleはコマンドだけ知っていれば実行できてしまうリスクもあるので、実行前に参照すべきドキュメントおよび「playbookのコーディング規約」を新たに制定した。 また、手作業で行なっているものを随時ansibleへ移行することで生産性の向上と再現性の担保を可能にした。（`2019年度実績で30本のplaybook`を作成） ansibleへ移行する際に検証環境をデータセンターのラッキングから全ての設定を自前で行い、作成ー廃棄ー再構築を実施する中でナレッジの蓄積も合わせて行った。 現在はAnsibel Tower / AWXといった`統合管理ツールを使うことで、ガバナンスの向上、オートメーションの推進とオペミスの低減、ナレッジ蓄積`を実装すべく、PoCを計画から実施まで一手にしている。（現在、実機検証の評価を実施中、導入の方向性で上申する） 3. まずは「当社のセキュリティ要件」の整備から着手、ベストプラクティスを参考に「何を脅威」とし、「どのように防ぐか？」を中心に検討を行なった。 外部よりも内部への対応が薄いと分析し、アクセスログの収集や確認の業務フローを立案。手作業になりがちな業務をAWS環境にShellプログラムを実装し、半自動でログ分析を行うことを可能にした。（`8h/月の工数削減`） また、特権に特化したセキュリティ対策を設計することで監査での指摘事項を減少させることに成功した。（2018年度は5件指摘、2019年度は指摘0件） そして、東証に上場したこともあり、より強固なセキュリティ対策が必要と考え、情報漏洩や改ざん等の対策をプロアクティブに計画している。 1.の記載と重複するが、`CSIRTの組織を1から立ち上げ、運営する事で関係者とのシナジーを創出する事に成功`した。 ## 工夫した点 * 参画直後からサイロ化している状況であったので、現状調査と分析に時間をかけ、`「今がどういう状況なのか？」をQDCを軸に明らか`にしていった。 現状では問題はないが、`再現性のない運用をしていることが一番のリスク`と捉えて、再現性の高い運用を実現すべく、実績のある手順を抽出して可視化することで、`今後起こりうるインシデントへの対策をプロアクティブに講じた`。 具体的には、`障害対応演習`を机上 / 実機で行うことで、`障害復旧手順の確立だけでなく、コミュニケーションルールの整備やスキルの可視化`を実現することができた。 * 「業務の可視化」が出来ておらず、属人的になっている業務を1つ1つひも解き、生産性を可視化するところから着手する事で、改善の効果も見える化した。 * セキュリティはほぼ考慮されていない状況であったので、`JPCERTやIPAが提示する内容をベースに守るべきセキュリティ要件を明確化`し、優先順位をつけて実装を行なっている。 * 関係する組織との協業を意識し、`どうすればより良いモノ作りが出来るか？という観点を常に持ち、組織を立ち上げ`、加速的に業務改善を推進する事を心掛けた。 * ansibleを効率的かつ統制を効かせて利用するためにAnsible Tower / AWXの導入について、机上検証・実機検証を行い、`商用利用する上での業務設計のポイントやつまづきやすいポイントの抽出を事前に行う`ことでメンバへ展開したときのイメージアップをしやすいようにした。 * 2020年からエンジニアマネージャーとして、組織開発・育成にも注力し、インフラ組織をSREへと昇華すべく、社外勉強会で得た知見をフィードバックし、エンジニアスキルの向上を目指している。

## 概要 * SUMMOに対するSRE活動 ## 規模 * 25名（自社5名、協力会社20名、40人月） # 役職 * リーダー ## 担当 * SRE活動の組織作りと組織構築PMO ## 環境 * 自社 ## 課題 1. インフラの業務内容が不透明（業務一覧、役割分担、責任分界点、など）で何かインシデントが起きたときのアクションが遅くなってしまう。 2. インフラの業務状況が不透明（インシデント件数、申請対応数、など）でKPIもなく、今が良いのか悪いのかすら把握できない。 3. 業務フローや手順書が整備されておらず、運用がブラックボックス。特定メンバが不在の場合、業務が滞ることもあった。 ## 成果 1. confluence / JIRAを用いて、インフラチームで対応している業務を整理・集計し、カテゴライズした業務一覧を作成。関係各所と認識合わせを行い、インフラの役割分担と責任分界点を合意した。 その結果、チームの枠組みを理解した上で協業するスキームも構築した。具体的には合意した責任分界点を意識しつつも`シナジーを生み出す為のコミュニケーション領域をslack上に構築し、ブレストや検討を行える透過性の高さ`を生み出した。（週に2件以上、業務改善・課題抽出を行うことを可能にした） 2. 業務をモニタリングする基盤をJIRAで構築し、JIRAを活用した業務フローを整備し、`インシデント件数や依頼業務の対応状況、メンバのスキル偏りを可視化し、リアルタイムに確認`できるようになった。 システムのモニタリング情報（JIRA / Datadog）はslackヘ連携する事で、システマチックに解決した。 3. 有識者から業務をヒアリングし、confluenceを用いて業務フローを可視化。他のメンバでも対応可能にした。 また、`各自で作っていたツールをGithubに集約し、共有のサーバ（RHEL＋Dokerで構築し、コンテナを利用）で稼働させることに成功`した。 上記に加えて、業務はansibleのplaybookに落とし込み、インフラメンバなら誰でも作業できる状態を作り込んだ。 ## 工夫した点 * 今までの運用で苦労していないメンバもおり、やり方を変えることに対してハレーションが起きないように「なぜこの活動をするか？」「この活動をすることで何が得られるか？」をメンバに腹落ちするまで説明し、協業して進めるようにした。 * インフラといっても範囲が広いので、通常運用を担当するメンバと課題解決を担当するメンバに役割を分けて、チーム内で責任分界点を明確にすることで、当事者意識を醸造し、生産性を上げるようにした。 * `自分のPCにvagrant+virtualboxで環境を作り、その中でansibleやDockerを稼働し、検証を行う`ことで検証の立ち上がりを早く、かつコストを抑えて取り組みを行い、実際にサーバを構築する前に上位層へデモを行なった。

## 概要 * 商用Webシステム定型業務担当チームマネジメントと安定運用 ## 規模 * 22名（自社4名、協力会社18名、530人月） ## 役職 * チームリーダー ## 担当 * チーム方針設定とモニタリング、安定運用に向けた業務改善推進 ## 環境 * 自社 ## 課題 1. 20名超えの体制だが、チームの業務量と必要工数がブラックボックスで、適正化できていない。 2. 業務で必要なドキュメントが存在せず、業務の内容や品質・納期が属人化している。 3. 上記状況であるにもかかわらず、業務改善が全くされず、凝り固まった業務になっている。 ## 成果 1. confluenceとJIRAを用いて、インフラチームで対応している業務と作業量を定量的に可視化し、月ごとの業務量と必要工数のシミュレーションを可能にした。 その結果、20名超えの体制から-6名で同じ量の業務を行うことが出来た。（`年間6,000万円のコスト削減`） 2. 有識者で業務内容の棚卸しとウォークスルーを行い、confluenceに業務フローと手順を整備していくことで、属人的でない業務を実現する事に成功した。 また、slackをコミュニケーションツールとして導入する事で、オープンな議論を可能にし、困っている事やトラブルをプロアクティブに吸い上げる事で、より高い生産性を実現する事ができた。 上記に加えて、納期短縮/コスト短縮をするためにansibleを導入し、事業側ともKPIを再定義を合意して、定常作業の自動化を実現した。 `自分で手を動かしてエンジニア作業を実施し、そこからの気づきをメンバーへフィードバックすることで納得感のある業務改善のサイクルを回せるように注力`した。 3. 私を中心に現状の業務を「課題→原因→解決策→効果」というフレームワークで棚卸しを行い、まずは課題・改善ポイントを可視化した。 進めて行く経緯をconfluenceに残す事で、業務改善のベストプラクティスとして他のメンバが何か改善のアプローチをしようとする時のサンプルとした。 PDCAサイクルを回すための`業務改善プロジェクトを立ち上げ、定期的に改善ポイントの抽出と対応計画の立案を行うスキームを装着`した。 ## 工夫した点 * 業務改善を経験したことない若手メンバがたくさんおり、「なぜ変える必要があるか？」「変えた先に何をしたいか？」を摺合せする事で、`中長期的にKPIをハイレベルで達成していきたいというマインドを醸造`した。 * `自分のローカル環境に本番環境をシミュレートした環境を構築し、ansible導入のハードルを下げるべく、フィージビリティを実施`。 ansibleを使う上での業務設計のポイントやつまづきやすいポイントの抽出を事前に行うことでメンバへ展開したときのイメージアップをよりしやすいようにした。 * ITILの資格を取得していた為、メンバに対して勉強会を開催し、サービスマネジメントのあり方や考え方、スキル・ナレッジをトランスファーした。 * 実務におけるヒヤリハットを共有することで、メンバの意識向上を促し、伴走することで知識の習得を効率化した。