こんにちは、ひろかずです。
2018年6月8日に行われた掲題のイベントに行ってきたので、一筆書きます。
会場は日本橋交差点の眼の前、コングレスクエア日本橋です。
空調は少し効きすぎでしたが、参加者の熱で感じないくらいになりました！
例によって、リアルタイム執筆です。
表記ゆれ、誤字、脱字はご容赦ください＞＜
お品書き
- 生き残る運用管理者 ～運用自動化を成功させる人、失敗させる人～
- エンタープライズのIT部門がSREになるには ～運用管理におけるAI／機械学習の活用の実際～
- リクルート流SRE インフラ運用がサービスを変える世界
生き残る運用管理者 ～運用自動化を成功させる人、失敗させる人～
運用設計ラボ合同会社 シニアアーキテクト
波田野 裕一氏
運用系マネージャはどれくらいいます？
- 少なめ
現場系の人ー？
- 割と多め
運用自動化を使う人は？
- 半数くらい
現実的な導入
- 失敗しないためという文脈
SRE本
- そのまま読むには、日本の文脈にはちょっと合わないかも
考え方、物の考え方を話していきたい。
バックボーン
会社が買収された際に、自動化を引き継ぐ相手がいなかったので、手動化した。
- ものすごく大変だった
今日は全体的に悲しい話かも
最近は、運用自動化への過剰な期待を冷却する人になっている。
「運用自動化」の不都合な真実
運用自動化は、業務を硬直化する
自動化された仕事はお役所仕事になる
やれることからやると、モノリシックになって、変更がしづらくなってくる
自動化は長く使えるは夢。リリースされた瞬間が価値の最高点で、負債になっていく
運用自動化は目的になりやすい
管理者、実装者のわかりやすい評価軸
見た目の成果に引きづられて、現場が苦労する
- 是非止めていただきたい
ユーザーにとっては、自動化は関係ない
- コストと品質があっていれば、どうでもいい。
- 自動化コストは客は望んでない
工数削減目的の自動化は自滅につながる
- 工数削減が目的化すると、運用価値を減って自滅する
- 空洞化して、対応できなくなるケースも有る
運用自動化は失敗する可能性が高い
夢のツールを目指すと、何がしたいのかわからなくなる。
- 多機能化
- 完全自動化
自動化によって複雑怪奇になって、手をつけられなくなる
自動化の寿命が短い
インフラ系はお客の顔が見えないので、失敗に陥りやすい
自動化で解決する夢が大きすぎる
Google SRE本とは前提が違う
序文を10回読む
- 4頁しかないから全然読める
Googleは遠い
第一部と四部は最高なので読む
自動化の第三部は捨てる
「運用自動化」が有効に機能するために必要な前提
目的ではなく、手段の一つと割り切る
- 職場のレイアウトやホワイトボード一つで解決することもある
ユーザーのメリットを常に意識する
- カウンターパートまで考えた自動化
工数削減を目的にしない
- QDCのうち、クオリティとデリバリーで語る
勝ち目があってやる
- 工数と効果を比較できるようにする
- 簡単ではない
自分たちの業務を客観的に見る
- お客に最適化されてるか？Amazonはカスタマファースト
- 自分達に最適化してないか？
- 業務の類似性や差異を把握しているか？定性評価。業務はドキュメントによって客観化されている必要がある
- 数値で比較して、主観が入る余地を排除する
欧米と日本のギャップはここにあると思う
「運用自動化」とは何かを考える
運用をサービスデリバリと捉える
- 運用の専門性は測りにくいが、サービス視点で設計を実装できる。
- デリバリ視点で評価できる
- サービス価値をお客にどう届けているかで価値が出る
- 全体プロセスのうち、どこを自動化するのが一番効果があるかを考える。隣の部署の自動化を手伝ったほうがいいかもしれない。
- 自動化にはコストが掛かる（時間をかけて低減していく）ので、コスト削減ファーストにはしない
大学の情報センターの人が減ってしまったのは、顧客視点がなかったからかもしれない...
論理的に正しいことを突き詰めていく
- 少なくとも論理が正しくなければ自動化は動かない
- 自動化前の指標がないと、何が改善されるのかは説明出来ない。（論理的ではない）
- 政治やなんとなくが横行している状況で、
手作業の電子化は進んだけど、抽象化、論理推論はまだまだ進まない
- 顧客視点での全体最適視点と論理能力がないと厳しい
自分たちの業務を運用自動化に向く形に変える
- 顧客視点での全体最適
- 適切に抽象化して、組み合わせ爆発が起きないようにする
- 適切に具体化して、現場に実装する
- コーディング能力は最後
運用現場への愛情と情熱が必要
運用自動化の導入ステップ
確実に効果があることだけを自動化する。
- 業務として大事なことだけ
トップダウンアプローチ
デリバリとクオリティ
- まず納期の現状と期待値を把握する
- 品質は、基準が主観になりがちなので、いきなりやるには難しい
運用の定型化
- 自動化の大前提として、
- 不要な業務(打ち合わせとか)を廃止するのが、自動化の実装より工数対効果も大きい。短期的に効果が出る。
- 業務棚卸ししないで自動化したらゴミになった
コアコンピタンス領域から手を着けるのが価値が最も高い
- 早急に手を付けるべき
自動化の実装
- 使う人が自分で設計、実装するしかない。
- 隣の島でさえ、使い物にならない。
- 自分で使わないと良さも悪さもわからない
- 実装はシンプルに、最小限に。
- 保守引き継ぎできる形に最低限にする
- 基本は内製。できるだけ実装しない。
導入後
- 必ず効果測定する
運用自動化は、サービスデリバリの自動化と捉えるとわかりやすい
失敗させる人
- 自動化ですべてを解決
失敗事例は世に出ない。失敗のほうが多い
成功したら
- 良くなったと言いに来る
- どうだった？で目が泳がない
- 第三者経由で喜びの声が来る
エンタープライズのIT部門がSREになるには ～運用管理におけるAI／機械学習の活用の実際～
日本ヒューレット・パッカード株式会社
最近の運用管理の現場をどう見ているか？
工数とトラブルを下げる話が非常に多い
- 止まってくれたほうがありがたい。治すしかないから。
- 止まらないのは、逆に質が悪い。
- 心の重さ。エラーの多さ。プレッシャーがある
コストセンターとして見られる向きは？
- 情熱は必要だが、このコストセンターとして要られている状況では難しい
煩雑な業務をなくすには？
HPE InfoSight
- トラブルが起きると業務が止まるので、トラブルの予兆
- 全世界の機器データを5分に一回集めて、分析して顧客に連絡している
- 稼働状況をみてAIが判断すれば、障害を未然に防げるかも。
- 7年前からある。実績を蓄積して、93%のケースが自動的にオープンされて、86%のケースが解決策の提供によって自動的にクローズされるところまできた。
- 連絡が来た時点でレベル3のエンジニアをアサインして、コア解析に入る
- レベル1,2のエンジニアが要らなくなった（ので、レベル3に上げるように育成している）
- サポートエンジニアの人数は減ってはいない。
運用が楽になっただけではもったいない？
工数下げるのがゴールではない。
エンドユーザーに新しい価値を提供できるかがカギ
- 運用が楽になって手が空いたら、最新動向をキャッチアップしてもらいたい
- それによって、目利き力を上げるのが、これからは大事になっていく
DevOpsのように、使う人と作る人が一緒にやっていく。インフラの世界にもそうなってきている。
ハードウェア設定をコード一行でできるようにする。
- アレイ設定はそうそう変更しないけど、ソフトウェアの変更に合わせて、柔軟に変更する時代なのでは。
- コード化されれば、開発側に作業を依頼できるのでは
HPE OneSphere（日本未展開）
- パブリッククラウドとオンプレミスを跨いで、シンプルなマルチクラウド管理を提供
- プロビジョニング時にクラウドとオンプレを選べる
- 次のバージョンでは、マイグレーションエンジンが実装される。うまく行ったら、パブリック移行出来たりする
具体的にはどう変わっていく？
- ハイブリッドIT
- InfoSphereと統合して、AIが配置の最適化を考えて、実施する未来
- タグ管理で、クラウドに移動させないようなコントロールもできるだろう
- インフラは、工数削減ではなく、インフラをコントロールすることで、どのようにビジネスに寄与できるかという立場になっていく
インフラ開発者の立ち位置
- 長く考えて設計したものを長く使うのは時代に合わなくなっている。
- アプリは既にあるので、インフラをリニアに実装できるようして、スピードに追いついていく。
- SLA担保したければ、オンプレ側がいいんじゃないか
HPEとしての今後の展望
どこでうごいている、から柔軟にきちんと動かすに。
- それを実現できる機能を提供していく。
- 壊れ方の分析によって、機器の信頼性を上げていって、ネガティブな障害を減らしていく。
ハイパーコンバージドインフラ
- クイックスタート、イージースケールアウトは、まだまだ仮想主体
- ソフトウェアディファインドで、CPUリソースが持っていかれたり、する
- 超高レイテンシ要件の場合は、物理の方がいい。
- SLAによって、物理か仮想化を選べて、コードで管理できるようになっている。
- ハイパーコンバージドインフラをやっているインフラ担当者は、開発に近いことが多い
メッセージ
インフラ担当者は、ビジネス価値を提供する側に回って、つまらない業務はAIに任せることで、よりプレゼンスが高まっていくだろう。
リクルート流SRE インフラ運用がサービスを変える世界
株式会社リクルートテクノロジーズ ITソリューション統括部 サイトリライアビリティエンジニアリング部
河村 聖悟氏
SREとは
サイト信頼性の向上が命題
- インフラの信頼性ではない
自動化やOSS導入が全てではない
ソフトウェアの考え方は運用で生きる
SERを通じてやってきたこと、学んできたことをシェア
- 運用はクリエイティブなこと
捨てた話(検索して！)
- リクルート SRE
- RAFTEL Fleet
- リクルートテクノロジーズ k8s
なんで改善施策しようとしてのか？
大人数で全員サッカーやってた
- 関係者大杉
- トリプルチェック
- 一つやるにも時間がかかる
- 特別なやりやすさはなかった
- 塩漬けもあった
- 今までやっていたことを変えたいというのもあまりなかった
リクルートのシステムは新旧混在
- クラウド利用はどんどん始まってるが、殆どの既存がオンプレミス
リクルートらしさ
- なんでやるの？を聞いてくれる人がいる
現状を知る
担当範囲関係なし
ドキュメント読みまくり、ヒアリングしまくり
仕組み化を考える
情報が揃ったら、仕組み化（フロー化）する
工程を減らせるか？の視点
仕組み化の前に考えること
無理な自動化は、避ける
- メンテナンスコストがかかる
その自動化が他に使える時間を生み出すか？
余計な仕事を作り出してないか？
独りよがり(俺すごい、誰も読めない)は良くない
自動化が効果的ではない例
部分的な自動化は、一部短縮しても、結果確認とかで、結局変わってない。
自動化で時間を作り出す例
自動化が自動化を連携して、結果確認までやる。
どんな自動化をやった？
Excel撤廃
申請書がそのまま実装されるツール
slackにHubotを作り込みまくる
抵抗に抗う
運用は減点方式なので、変化を嫌う
運用フローを分析すると、イン・アウトがある。
イン・アウトを揃えて、中身を自動化
諦めないで説明する
システムは変わらないが、人は変わるので、変化しない運用は品質が下がる
手動化のほうが安定するは都市伝説
属人性を剥がす
属人性は品質を下げる
冪等性
仕組み化を考える過程で属人性が有効に効く
要らないアラートは捨てる
アラートを潰すのは、有効な運用効率化
障害発生しても良いシステムは、記録だけ残す
コミュニケーションをオープンに
インフラだけに閉じずに、広く関係者に話す
インフラに対してフランクに相談できる環境を作る
閉鎖的なコミュニケーションのコストは尋常じゃない
チームに閉じたツールは撤廃
部署を分けて、サービスに寄せた
チームを切り出して、サービスの場所の近くに配置した。
障害の温度感が伝わるようになった
ロケーションを縮めるのは良かった
反省としては、役割定義の明確化
インフラ作業申請の形を変える
フリーフォーマットを減らす
人間チェックはほとんど不要
ロケーションを知覚して、会話して、記録を残す
監視・モニタリングを変える
ログ目視は、全体障害に弱い
メトリクスは全部取って、問題が起きそうなところに絞り込んでくる
組織として振り返る
失敗した人の減点やどやしはやめる
失敗のカバーは、その作業をやらないようにするということ
技術的なものさしを世の中にあわせる
技術のものさしを世の中に合わせないと、人材の流動性が下がる
(知るために)対外活動の積極的励行
結果、どのように変わったか？
定常運用人員は一年間で50人減った
オンプレミスの数は増えた
自動化を進めてわかったこと
自動処理
ルール判定は、人の判定より正確でミスがない
不要な雑用を見抜いて変える
作業は全部把握する
自動化ではなく、要はなくせばいい
運用改善に王道なし
リソースを変えずに改善するのは無理
- 投資コストを見据えて、リソースを投下して改善していくのが健全
疑う
本当にその作業は必要？
今あるものを勇気を持って捨てる
なんとなく続けていることはたくさんある
要るか要らないかは、広い視野で見ないと事故る
運用で守るものをもう一度考える
サービスを動かすこと
- インフラを動かすことではない
障害を捨てられる設計ができれば勝ち
サービスレベルに合わせたリスクマネジメント
- 24365の全員サッカーにならないようにする
サービスがよくなったのかを考える
サイト信頼度が重要
やってみる
守らないといけないこと
- 本番環境
- 作業手順見直しは、そんなに慎重になること？
- 検討は進まない。まずやってみる。
満点を目指さない
改善できるならやって見られることはやってみる。
満点じゃないからやらない、花にも変えられない
挑戦できる土壌
個人の失敗を責めない
- チーム内だけでも前を向く
なにも変えないで発生したミス
- 絶好の改善タイミング
振り返る
失敗・障害は振り返りミーティングで時間を書ける
次の芽が生えるかの瀬戸際
リクルートは機能要件で成り立っている
非機能性能をモニタリングして、分析や基盤インフラ改善のサイクルを回す
一回全部見えるようにする
おかしいところは、全部見てから気づく
非機能要件の見える化によって見つかる例
多段リダイレクトによる遅延
特定URLリンクからの大量404
etc
終わりに
運用はアイデアで変えられるクリエイティブなもの
現場感満載の素敵なセッションでした！
今日はここまでです。
お疲れ様でした。