- 変更/回収フローを容易にした事で再現性が担保され、気軽に更新/改修ができる
- これまでの運用方法では、一度作った環境を更新/改修することにリスクがあった
- ステージング、本番環境は人間が直接操作しない
- インフラのCI/CDを作り込むことによって、各環境に直接触れる必要がなくなった
- 構成管理が自動化かつ簡単なフローで行えることで、「これは急ぎだから手でやってしまう」という気持ちをなくすことができた
- 将来の改修容易性を踏まえたSimplicityと、日々の運用容易性を踏まえたEaseを意識してフローを作ったことによる恩恵
- これまでは、OSのインストールから行うため、作る工数が高く、使う側の視点は「載せるものが動けばOK」程度に留まっていた
- 基盤にとってアプリはブラックボックスで、触るものではなかった
- アプリケーションのデプロイ方法などは開発のチームに委任していたため、チームごとに同じ技術を使っていてもやり方が異なるなどの問題があった(そもそもインフラ側では踏み入れる領域でもなかった)
- パブリッククラウドを使い始めたことで、基盤を使う意識が強くなった
- ドキュメントを読む機会が増えた
- 下のレイヤーを意識する範囲が減ったことで、より最適な使い方を考えるようになった
- コンテナを使っているため、アプリケーションのビルドやデリバリーを開発と一緒にメンテナンスするようになった
- お互いに全部見ないといけないというわけではなく、この箇所はアプリの都合でどっちが見たほうが見たほうがいいみたいな共通認識は揃えるようにしている
- 検討、検証のフェーズが短くなった
- 基盤を1から作ることがないため、比較検討の段階で最適なものを提案するところにまで手が回るようになった
- 動けばOKが通じない世界になった
- 基盤を1から作ることがないため、比較検討の段階で最適なものを提案するところにまで手が回るようになった
- これまでは、マネージドサービスなどがなく自分たちでソリューションの選定から行っていた
- 各分野に強い専門性があり、メンバーごとに業務が分離され、属人化に繋がりやすかった
- 個人の作業がある担当範囲における進捗に直結するため、自由に働くことが難しかった
- エンタープライズ製品の知識については、先輩から伝授してもらうことが多かった
- これまでは、ドキュメントと手順書が両方存在していた
- 車輪の再生産をせずとも用意されたソリューションを利用できるため、継続的に運用しやすくなった
- 基盤部分のドメイン知識が強く求められないため、複数人でタスクを共有してもある程度回るようになった
- 基盤を共通のツールを使ってコード管理するようになったため、ドキュメントと合わせてクロスレビューできるようになった
- レビューの段階で知識をシェアすることが当たり前になったので、担当外でもある程度面倒を見れる範囲がお互いに増えた
- 自宅での勤務やある程度自由な時間での勤務ができるようになった
- オンコール対応やアラート対応も、担当範囲による組み合わせを考慮する必要がなくなった
- クラウドネイティブな基盤ではインフラのコード管理が根本にある
- 実装はコードに、思想はドキュメントに記載するようになった
- ドキュメントが残されているので、一子相伝よりもそれを見て不明なところは自分で調べたり聞きに行ったりするようになった
- これまではオンプレだったので、「DC内へのアクセスをどうやって制限するか」がメインで設計していた
- 一般に公開するサービスはクラウドであってもこれまでと同じように、外部からのアクセスをどのように制御するかを考慮する必要はある
- 構成のコード管理を始めたことで、これまで蔓延していたスクリプトへのベタ書きのパスワードや、平文で情報を保存する文化を見直すきっかけになった
- GoDaddy製のKubernetes External Secretsを用いてアプリケーションの秘匿情報をGitのKubernetesマニフェストに載せずに管理する手法の導入
- トラブルシューティング時のSSHをやめるために踏み台サーバーを使わずEKSのノードにAWS SSMエージェントを入れてSession Managerを使えるようにした
- サーバー購入に関しては一度買ったものは固定費として償却されていくので、それをどう使おうがコスト自体が大きく変わることはなかった
- 機器の手配やキッティングなどを考慮した時間配分が必要なため、スケジュールも全体的に長くとることが多かった
- クラウドの場合、使ったものが使った分だけ課金されるため、スポットやリザーブドのインスタンスなどを活用しつつも、さらにコスト感を意識するようになった
- 構築までの準備がほぼ不要なため、タスクに手を付けるまでの時間が一気にゼロになった
- これまでのスケジュール感と全く違う概念で、慣れるのに時間がかかった
- タスクをこなす時間がそのまま全体の時間に直結するため、個人のスキル次第で必要な時間の見積もりが変わったり、こなせるタスク量に差が生まれると感じた
- ある程度レベル感を問わないオンボーディングの重要性
- これまでのインフラエンジニアとしての働き方では、障害が発生したときも一次切り分けをしてアプリケーション起因のものは全て開発チームに任せていた
- 今は自分たちもソフトウェア開発の手法を積極的に取り入れるようになった
- 自律制御を行うKuernetesという基盤を取り入れたことによって、サービスの正常性を保つ範囲は全て担当するようになった