2年半のSRE業で行ってきた事の整理
直近2年半くらいの間にSREチームのリーダー（マネージャー）、ならびにシニアエンジニア（スタッフエンジニア）としてSRE業を行ってきました。
私は過去にSRE専業の経験はなく、この会社にもSREとして入ったはずではなかったのですが、なし崩し的に入社時の取り決めとは異なる職につくことになりました。
とはいえ、今までのキャリアはサーバーサイドエンジニア・バックエンドエンジニア中心ということもあり、アプリケーションの開発にあわせてシステムの構築や監視などもずっとやってきたので、SRE的なスキルは具備していたと思います。Datadogも何気に使いはじめて10年以上経ってます。
2年半の間、客観的に見て大したことはやってきてないですが、自分のこれまでとこれからを見通すための備忘録として、やってきたことをまとめてみたいと思います。
会社
会社は創業10年くらいの中小企業で、BtoC系。ビジネス規模としては売上が年あたり数億程度で数年停滞している会社です。ここ数年は業績は右肩下がり傾向です。
オフィスの環境も、椅子は壊れていて、モニターも少なく、ネット回線は遅くてつながらない、みたいな環境だったので、会社出社派の私も仕事を円滑に進めるために泣く泣く在宅中心で働いていました。
その状況を包み隠して、対外的にはイケてるベンチャーとしてアピールをしているという側面もありました。
システムとしては、創業当初からAWSを使っていて、ほぼ全システムがパブリッククラウド上に構築されていました。
技術的にやったこと
仕事としてはリーダー（一般的な会社におけるマネージャー）としてヒューマンリソースの管理や組織の改善を行ってきた側面もありますが、この記事ではスタッフエンジニア的な振る舞いとして行った技術的な課題解決のみを記載していきます。
Observabilityの向上
私が入社する前からSREチームは存在していたようなのですが、あまりSRE Way的なものが実践されていませんでした。
その代表格が「監視」で、Datadogは契約しているけどMonitorの設定はされてない（もしくはお試しで作りかけのものが放置されている）、かといってCloud Watchでも気が向いた数台だけなんとなくAlarmの設定がされている、という状況でした。
端的に、システムに対する監視が網羅的に行われておらず、DBやコンピュートエンジンがCPU使用率100%になっていてサチっていてもSREの誰も気づいていないし、他の社員ももちろん気づかない。顧客からのクレームによりはじめて異常に気づく。
みたいな状況が私の入社前は常態化していたようです。
幸いにもDatadogは契約だけは行われていたので、これを使ってObservabilityまわりの環境を一通り整理しました。
- Monitor
- Runbook の整備含む
- Dashboard
- APM
- RUM
- SLO
- Synthetic Test
- Datadog Logs
- Cloud SIEM
- Sensitive Data Scanner
Aleting は Monitor、可視化は Dashboard、システムの調査はAPM・RUM・Datadog Logsあたりを中心に実施する体制にしました。
セキュリティ的な取り組みについても後述しますが、網羅的なSecurity Incidentの監視のためのSIEMツールについてもDatadogを用いて構築しました。
これらの取り組みによりシステムに対するObservabilityが向上し、結果今まで目に見えてなかった様々なシステム上の問題が可視化されることになります。それらの課題解決につても後述。
また、Datadogの設定について手作業で行ったりすると、面倒ですし作業者によるムラも出てしまうので、Terraformを用いて設定のIaC管理もあわせて行いました。
技術的な話とは言えないですが、ミーティングでの情報共有の仕方も整理し、Datadog の Dashboard を元にしたシステムメトリクスの振り返り会を毎週実施するようにしました。これも私の入社前は一切行われてなかった事のようです。
アラート未満のシステム的な異常値・兆しについてこの場で気づくことが多く、問題が顕在化する前に施策を行なうことができるようになりシステムの安定化に貢献したと思います。
どこでもやっているような事でしょうが、基礎的な所作が行われている・行われていないの差で、顕著にSREチームのパフォーマンスにも差が出るものだなとあらためて感じました。
システムのパフォーマンスチューニング
Datadogによるシステム状況の可視化を進めることにより、システムが抱えているパフォーマンス周りの問題が見えてきました。
パフォーマンスの問題
- 日常的にDBのCPU使用率が100%になる（性能キャパシティの問題）
- サービスの画面表示速度が遅い（レスポンス速度の問題）
- 大きなデータを扱うプロセスがOOM Killerにより殺されてエラーになる（可用性の問題）
APMなどで状況を分析すると、これらの問題の原因の大半は発行されている SQL のパフォーマンスが悪いことでした。
パフォーマンスの問題は、内容によっては顧客からのクレームの対象となっていたので、優先度の高い課題としてSREチーム中心で対応を行いました。
KPI の整理
まず、対応するにあたって目指すKPIを定めました。
- DB CPU 使用率: 100% -> 50%
- レスポンス速度: LCP（Largest Contentful Paint）を 2.5s 以下に
- OOM: 発生させない
これらについては閾値を超えたら Monitor で通知するようにしたり、適切な Dashboard を作成し各種ミーティングなどで状況の確認・振り返りを実施するようにしました。
問題解決
そのうえで問題の解決を実施しました。
具体的には、APMを見て時間のかかっているSQLを特定したうえで、改修のインパクトが大きい、改修のコスパが高いものから優先して実施をしていきました。
大別して以下のような対策を実施。
- 適切なIndexの付与
- DBのテーブル構造の最適化（あわせてプログラムの修正）
- 画面仕様の変更（重たい処理を実施しないよう、機能要件の変更）
SREチーム自らコードやDBの構造を変更してリリースするケースもありましたし、開発チームに修正をお願いするケースもありました。
結果
これらの対策により、3ヶ月くらいで DB の CPU 使用率はピーク時の負荷が1/10に改善（100%→10%）。
レスポンス速度の改善はもう少し時間がかかりましたが、一部の仕組み的に改善が難しいものを除いた主要なエンドポイントについて LCP Green を達成しました。
性能改善後も、SREチーム主体で定期的にシステムを監視し、問題が起こっている、もしくは起こりそうな箇所があったら開発チームに連携する体制もあわせて構築しました。
新機能の開発でまた遅い処理を乱造されてしまってはシステム改善をした甲斐もなくなるので、システム開発の指針としていくつかベストプラクティスをまとめたドキュメントの整理と周知なども行いました。
システム予算の管理と適切なシステムスケーリング
最近はFinOpsという言葉も普及しており、クラウドシステムの戦略的な予算管理は組織の重大なテーマの一つになっています。
私入社時は施策が全く行われておらず、Reserved Instanceの購入も2019年くらいにお試しで1回行われた跡は放置されているといった状況でした。
システム費用の管理がされてないと、お金の使い方に皆無頓着で野放図になるというより、誰も適切な予算がどれくらいなのかわからずシステムに対する適切な投資が行えない、ということが課題だと感じました。
なので、現行のシステム費用を最適化したうえで、今後のサービス成長にあわせたシステム投資戦略の構築を行いました。具体的には以下
- コスト管理用のDashboardを構築し可視化
- 日・月・年単位で整理
- 日々の費用の増分や、将来の予測についても可視化
- コストカット・コストダウンできることはできる限り実施
- Reserved Instance , Savings Plans の導入
- 使ってない不要な機能は削除
- 使用してないのに契約だけ続いているSaaSは解約
- 感覚的に選ばれたサーバーのスペックやインスタンスタイプの最適化
- 想定外の費用増を検知するために Datadog の Anomaly Detection を用いて異常値分析を実施
- 浮いたお金を使って本来投資すべき箇所への適切なシステム投資
コスト削減・最適化
AWS については Reserved Instance / Savings Plans の導入を半年に一度行なう体制にしました。費用的には「全額前払い」のほうがお得なのですが、手元のキャッシュが足らない会社だったので経営管理側が難色を示したので「前払い無し」プランでの導入となりました。この辺は会社の経営状況との兼ね合いも必要です。
AWS以外にも例えばDatadogでもMonthlyで使用料をコミットすることで割引措置が得られたりするので、そういう感じで各クラウド・SaaSをお得に使えるようなプラン設計もSREが行いました。
また、一部のEC2インスタンスがt2,t3などのバーストインスタンス（Unlimited）になっていたのですが、定期的にバーストして想定より多く費用を垂れ流していたのが現実でした。c系やm系のインスタンスに変えて安定した性能と予測しやすい費用体系に置き換えたりもしました。
想定外の費用増についての監視も追加し、想定したラインよりも月額費用が多くなりそうなものについてはDatadogによりアラート通知がされるようにもしました。
AWSのCost Anomaly Detectionでも良いのですが、これだと月単位の費用ベースでの通知になり対策が手遅れになりがちなため、Datadogで独自のMonitorを作成しできるだけ早くAnomalyな状況に気づけるようにしました。
この対策により以下のような状況に気づけました
- ECR の使用料が急激に増えた
- GitHub Actions から ECR の特定 Image の Pull が大量に行われていて、それが費用増につながっていた
- → CI用の Image は GitHub 側に Push するようにして費用節約
- VPC Endpoint の費用が増えた
- アカウント間で接続を行っている箇所について AWS Private Link で接続し、各アカウントから VPC Endpoint を用いて AWS リソースに接続するようにしていたが、コンポーネントが増えることによる費用増加が無視できなくなった。
- → 一部ネットワーク構成を Private Link から VPC Peeringに移行。VPC Endpointの使用を最低限にすることで解消
システム投資
月額の費用、今後の増分の費用を最適化施策で抑えるようにしたうえで、必要なのに手を付けられて無かった部分へのシステム投資を行なうようにもしました。
- Compute Resource が足らないのに雰囲気で節約していたものに対して適切なリソースの確保（EC2、ECS）
- Availability 向上のためのシステム構成の冗長化。SPOFの排除
- SLO の Budget が枯渇した際に、コンピュートエンジンの性能不足が起因の場合増設を行なう
こういう形で、まず費用を削り、節約した費用を使ってより本質的なシステム構成への投資を実施。だけど費用は今までよりも抑えられている。みたいな状況を作りました。
もともとが何も管理されてなかったので、過去と比較しても意味はないかもしれませんが。
余談ですが私はFPの資格（AFP）を所持しており、かつ私生活ではポイ活マニアなので、中長期的なマネープランを作ったり、お得になる購買戦略を考えたりするのは日々行っているので、FinOps周りの対応は比較的楽しい仕事でした。
重大なログの監視と撲滅作業
システムメトリクス周りの監視も行われていませんでしたが、ログ周りの監視もあまり実施されておらず、重大なエラーが見過ごされているのも常態化していました。
そのため、顧客に影響があるエラーが発生しても見逃され、顧客に指摘される、という恥ずかしい事態も比較的多く発生していました。
Critical Log の対応
ログについて、「これが発生したら即障害」というレベルのログ（社内用語で「Critical Log」と呼称）を整理し、個別にアラート通知を行なうようにしました。
大半は開発サイドでの検証・テスト不足によるNull参照エラーでした。
SREチームが直しても良かったのですが、各チームに責任感を持ってほしいという思惑もあり、アラートが飛んできたらできるだけ速やかに開発チームに共有し、修正するのは開発チームの責任で実施。というような体制を作り、運用をするようにしました。
この対応により、対応を開始してから3ヶ月くらいで、概ね重大なエラーについては撲滅することができました。
Slow Query Log (Lock time） の対応
単純にSQLの実行時間が長いものについてはDatadog APMでも検知ができるのですが、「ロックの時間が長い」ものについては判別が難しく見逃していました。通常時は問題ないが、ロックが競合する際に性能が劣化する、というケースです。
MySQL の Slow Query Log には Lock_time という項目名でロック時間も出力されています。
# Time: 2024-09-03T03:10:54.745582Z
# User@Host: sada[sada] @ [xxx.xxx.xxx.xxx] Id: 1234567890
# Query_time: 0.518726 Lock_time: 0.000040 Rows_sent: 0 Rows_examined: 1493362
SET timestamp=1725333054;
select * from `sada`;
Slow Query Log を解析し、こちらを元に過剰にロックがかかっている SQL を特定し、修正を行いました。
広範囲に行ロックが長時間（0.5秒くらい）かかっていて、単発の処理では気にならないけど複数件同時にリクエストが来た際の並列処理に支障が出ている箇所を、この調査により特定したりもしました。
HTTP 5xx エラーの削減。もしくは適切なHTTPステータスの返却
多くの会社だとエラーログの監視というのはWebレイヤーでHTTPステータス500番台を返却しているものの監視、ということになると思います。
この会社では1日あたり数千件の5xxエラーが発生していて致命的だなと思ったのですが、エラーの内容を細かく解析していくと「本来5xxエラーを返さなくてよいのに5xxを返している」というものが支配的でした。例えば Web レイヤーでの入力値のバリデーションエラーの際に500エラーを返却しているなど。
開発チームが基礎的なHTTPの仕組みをあまり理解していないしステータスコードのテストもしてないという事を示唆する状況なのでそれはそれで頭が痛いのですが、問題箇所を特定しつつ開発チームに都度指摘をしてHTTPステータスの最適化を行っていきました。
そのうえで残り続ける5xxエラーは
- 500: アプリケーションのバグ（上述の Critical Log 含む）
- 504: アプリケーションのタイムアウト
が支配的でした。タイムアウトについてはSQLのパフォーマンス劣化が主な理由だったため、都度開発チームとコミュニケーションをしながら修正をしていきました。
IaCカバレッジの向上
私が入社する前は、システムの構築は基本手作業、よくてオレオレshellが用意されているのみ、という状況でした。
そのため、インフラが誰にどのような意図で構築されたのか、後から入社した私のような人間は把握できないですし、構築したはずの既存メンバーも忘れているという状況でした。
そのため、インフラ構築についてもIaC化を推進しました。以下あたりが目的です。
- 誰が構築しても同じような環境が作れるようにする
- 設定をGitHub管理にすることで設定内容のレビューや変更差分を追えるようにする
- CIを充実しセキュリティ的な問題を未然に確認できるようにする
- CDを自動化し構築の手間やミスを削減する
IaC 化の対象
今回はTerraformを採用し、以下のクラウドリソースについては基本的にTerraformで管理をするようにしました。
- AWS
- Google Cloud
- Datadog
- Monitor、Synthetic Test、他各種設定
- GitHub
- ユーザー、チーム管理、GitHub Actions Secrets など
AWSなどについてはすでに作成済みのリソースも多かったのですが、既存のリソースのうち早めにIaC管理下にしたいものを計画的にTerraform化していきました。
具体的には既存の設定をImportし、Import後はかならずTerraformから修正する、という流れです。
このプロセスを踏むことにより、既存の設定の理解度が高まり、「ここは直した方が良い」という箇所にも気付きやすくなるため、結果的にただImportをしただけで終わりではなく漸進的なシステム改善につながりました。
余談ですが、GitHub は最初はリポジトリのテンプレート的な構成をTerraformで用意して、主要なリポジトリに対して同じような設定を統一して行なうことを目指してましたが、あまりに組織の皆が自由にリポジトリを作ってしまっているので断念し、ユーザーの管理のみに留めました。以前私がいた会社（社員1万人くらいいる会社）でも似たような状況だったので、組織規模によらず似たような形に落ち着くのかなと思いました。
一応、GitHub Actions の Secret については Terraform 管理しないと登録された Secret が何者なのかわからなくなって詰むことが多かったので、対応をしました。
module化の徹底
Terraform化を進めた当初は、非常にシンプルなディレクトリ構成で、フラットに多くのリソースについての記述を行っていましたが、対象とするリソースが増えるにつれて管理上見通しが悪くなり破綻が見えるようになりました。
なので破綻する前に module 化を徹底するように切り替えました。
方針についてはTerraformの公式ドキュメントに style guide が用意されており、こちらに module についての記述もあるためこちらに準拠するようにしました。
AWSのリソース等について記述量が減らせるという恩恵もありましたし、地味にDatadogのMonitorの閾値やアラート文面などのゆらぎをシステム横断的に統一できたので、module化に踏み切って良かったなと思いました。
HCP Terraform(Terraform Cloud）
Terraformの推進をしていると、CI/CD環境とローカル環境での実行結果のズレに頭を悩まされるようになりました。割り当てられているIAM Roleの権限が異なる事が多いのが原因です。
他にも、ローカル環境でTerraformを実行する際に設定が必要な各種Credentialの扱いや、Stateファイルの扱いにもセキュリティ的な課題がありました。
これらを一足飛びに解決する手段としてHCP Terraformを採用しました。
HCP Terraform についてはzennにも色々記事を書いています。費用的な投資は必要ですが、それを補って余りあるメリットが得られたと感じています。
CI/CDの改善、コード品質の測定
CI/CDについても、一般的な会社に比べると対応レベルが何段階か落ちていました。
一番特徴的だったのはCode Coverageの測定が行われていなかったこと。そのため開発者が自発的にテストケースを書くというモチベーションにもつながらず、テストを作成することがサボられてしまい、結果的にテスト不足による障害が多発していました。
テストカバレッジの測定（CodeClimate）
カバレッジについて、測定を自前で行っても、コミットごともしくはPullRequest単位ごとにカバレッジを測定して可視化する仕組みを作るのは手間がかかります。
そのため、この部分については自前化を諦めてSaaSの導入を行いました。
今回はCodeClimateというサービスを使用しました。
CIフェーズで適切にテストを実施しカバレッジレポートをCodeClimateに送信すると、いくつかの機能が使えるようになります。
- Code Coverage の可視化
- CodeClimate の画面で、ソースコード単位でカバレッジの状況について確認できる
- 自動レビュー機能
- PullRequest による Code Coverage の変化を自動的に GitHub にコメントしてくれる
- PR により Coverage が下がる場合は Status = fail 扱いになる（マージできなくなる）
- コードの品質の測定（Code Smells）
- Coverage によらず、コードの記述の中でバグを生み出しそうな記述がある場合指摘をしてくれる
- PullRequest のコメントに自動的にレビューが行われる
カバレッジが可視化されることにより、開発エンジニアも適切なテストを以前よりは書くようになったため、品質向上には確実につながりました。
また、CodeClimateでは自動的にコードの良くない部分についてレビューをしてくれるため、結果として組織の生産性についても向上しました。
今まではレビュワーに負荷が集中しており、レビュワーが反応しないとPR作成者は手持ち無沙汰になり、レビュー〜マージまでの待ち時間の多さが生産性に悪影響を与えていました。
自動的にレビューをしてくれることでPR作成者も自律的に改善アクションを行えるようになり、結果的にレビュワーの負担も減り、マージまでのアイドル時間も大幅に低減しました。
なお、この辺の「生産性」については merged-pr-stat を用いて定量的に分析をしました。便利なツールありがとうございます。
他Linter
CodeClimate 以外にも、各種 Linter についてはできる限り設定し、誰が実装をしてもベストプラクティスを踏襲できるような環境の整備にはそれなりに時間を使いました。
例として Terraform 関連のリポジトリには以下のようなものを設定していました。
- actionlint
- tflint
- yamllint
- tfsec / trivy
-
tfupdate
- 正確にはLinterではないが、Terraform 本体/providerのバージョンアップを検知したら自動的にPullRequestを作ってくれるツール
Reusable workflows / Composite action
これは CI/CD 環境構築のテクニックでしかないですが、GitHub Actions を使っている場合は再利用可能な workflows / actions を有効活用することで記述のスパゲッティ化を抑制することができます。
この辺も比較的徹底して行いました。
セキュリティ対応
セキュリティ、と書くと、対象となる範囲が膨大になります。私も2年半ではやりたいと思った事のすべてが実施できたわけではありません。
一応、やってきた事を五月雨的に記述します。
セキュリティインシデント検知の整備
AWSの中でも、セキュリティ関連のインシデント・イシューについて検知するための仕組みが多数用意されています。
- CloudTrail
- Inspector
- Guard Duty
- IAM Access Analyzer
- Security Hub
- etc
これらのツールを適切に有効化し、攻撃やセキュリティイシューについて気付けるようなシステム構成にしました。
AWSに閉じずに他のクラウドサービスも含めて網羅的に Security Incident を検知できる仕組みが必要だろうということで、追加で Datadog SIEM についても導入を行いました。幸いなことに今のところCriticalなイシューについては検知していないようです。
SCA / DAST の導入
depndabot や VAddy などのツールについて。
特に VAddy は、これも契約だけされているけどまともに使われていない、というひどい状況だったのですが、QAチームなどと相談をして開発プロセスの中に組み込むようにしました。
- リグレッションテスト: 既存の画面・APIに対して1日1回脆弱性診断を実施
- QA: 新規開発された画面・APIに対して、リリース前のQAフェーズで診断を実施
開発者もQAサイドも、診断をしているという安心感が得られて良かった、というフィードバックをもらいました。もちろんこういう施策というのはやっていて当たり前、行っていないのは顧客に対する背信行為である、とは思いますが…
データセキュリティポリシーの作成
「セキュリティ」を向上させようとした場合、そのための基礎的な指針が必要になります。
データベースやログに書き込むデータについても、どの内容は書き込んでよくて、これは書き込んでは良くないという「指針」がないと、何が正しくて何が正しくないかもわからないです。
そのため、基本となる指針の策定を行いました。
詳細についてはあまり口外すべきではなさそうなので割愛しますが、個人情報保護法など、国内法規に基づいてRed/Yellow/Greenなどにレベル分けをして策定をしました。
セキュリティインシデント発生時の体制構築（CSIRT / CSIRP の策定）
組織として最低限具備されているべき仕組みではありますが、存在していなかったので、経営層に提言をし、雛形は全部そろえて、お膳立てまでは全部行いました。
セキュリティ対応の副産物
これらのセキュリティ対応についての副産物として、顧客から依頼されるセキュリティチェックシートに対して、以前よりも高いレベルで回答ができるようになったことが挙げられるかなと思います。
そのことにより安心していただいて契約に結びついた顧客もきっとあることでしょうから、多少は会社の利益にも貢献できたのではと思います。誰からも感謝はされたことはないですが。
SRE Maturity Model
これはどちらかというとマネジメントよりかもしれませんが、SREチームが行ってきた施策や、その結果たどり着いた現在位置がどの程度の水準なのか、客観的な指標で測りたいというモチベーションから組織に対するMaturity Model（成熟度モデル）の診断を定期的に行ないました。
Monitoring SaaS 企業がそれぞれ公開していますが、私は Datadog に馴染みがあることもあり、Datadog 社の「DevSecOps 成熟度モデル」を参考に診断を行いました。
診断結果についての詳細はここには貼らないですが、「Observability関連（観察と応答）」については施策の効果もあってかなり高い水準に達していることを確認しました。
その一方「リリースとデプロイ」についてはあまり点数が高くなく、硬直化したデプロイプロセスが残存していたことが低い評価となりました。
デプロイメントパイプラインについては、IaCなどSREの範疇についてはかなり改善させることができましたが、アプリケーション本体については課題が残り続ける結果となりました。
いずれにせよ、このような形で自分たちの成熟度を診断し、出来ていることの把握、これから解決しないといけない課題などをあぶり出すためのツールとして使用しました。
その他
その他、この記事では書けない内容、あと一歩だったのに外的問題により頓挫した計画、等々数多の残骸・亡骸が存在します。
個人的には、システムアーキテクチャの抜本改善について、あと一歩でカットオーバーできるところまで行ったのに、政治的な理由で頓挫したことが悔やまれます。これが実現できていればシステムの安定化、費用削減、運用効率の向上に大きく寄与できたのに、という思いもありますが、総合的に考えて自分の力不足だなと感じています。
あと、一般的な Individual Contributor とは異なり、私はチームマネジメントや採用などにもそれなりに時間を割いていたので、技術者として本来やりたかったこと、やれたはずのことも出来なかったという側面もあります。この辺も、いまさら言っても詮無い話ですが、組織の理解がもう少し得られれば会社としても違う未来があったのにな、とは思います。
最後に蛇足ですが、この記事に書いているのは私がスタッフエンジニアとして自分の手を動かして行ってきた内容のみ記載しています。チームで行ってきたことの実績は他にもたくさんあります。
資格取得
SRE業は私にとっては新しい挑戦でもあったので、勉強もそれなりにしましたし、それを具象化したProveとして資格が存在するものについては資格を取得するようにしました。
会社からきちんと受験費用の補助が出る会社もあると思いますが、私はほとんど自腹です。
2年半の間に取得した資格は以下です。
- 個人情報保護士
- 情報セキュリティマネジメント
- 情報セキュリティ管理士
- 情報処理安全確保支援士（セキスペ）
- Datadog Fundamentals
- Datadog Log Management Fundamentals
- AWS Certified Cloud Practitioner
- AWS Certified Solutions Architect - Associate
- AWS Certified Developer - Associate
- AWS Certified Solutions Architect - Professional
個人的には資格は飾りでしかない部分もあるとは思いますが、該当知識・スキルを最速で身につけるためには、資格取得のために勉強するというのは効率的な学習方法だと思っています。実際実務にもそれなりに役立ったので、勉強をしたこと、結果として副産物で資格も取得できたことは無駄ではなかったと思います。
余談ですが、セキスペの試験は、結構IPAの人も考えて試験問題を作っていて、Log4Shellの対策を思わせるような試験問題が出たりと比較的実践的な内容でした。SREの人がIPAの試験を何か受けるとしたら、セキスペが一番マッチしそうに思います。
Datadog、AWSなどの企業系認定資格は、特に試験対策はせずに、力試し的に受験しました。AWSの試験は1ヶ月くらいの期間でまとめて受けました。
私は前職は会社のポリシー的にパブリッククラウドが使用できない環境にいたので、クラウド系の知識がこの2年半で多少は身についたことに少し安堵しました。
Discussion