オペレーション成熟度
Service Reliability Hierarchy
SRE成熟度評価シート
Observerbillity成熟度
おわりに
ここに全部書いてあった... zenn.dev
ここに全部書いてあった... zenn.dev
現職のSREチームのMVVを検討し始めてるので他社のMVVについて調べてみる
delyが持つ熱量と幸せをできるだけ多くの人に届けられるように、プロダクトの価値最大化をシステム運用において実現する。 その過程において最善の選択が何であるかを考え、システムの設計と運用を改善し続ける。
ユーザーにたくさんの価値を素早く提供できるようにしながら、事業の成長を阻害する要因を取り除く
SRE化を通して、Developer Experienceの改善、事業の拡大への対応、お客様に信頼されるサービスの提供を実現する
明確なミッションが書かれているわけではないが参考になるので貼っておく
今所属している会社にもCTO室があるが、他の会社がどのような背景・目的・役割でCTO室を設けているのか気になったので調べてみる。 インターネットで雑に検索して出て来たものをいくつかピックアップし、設立の背景・目的、ミッションなどで共通項があるかなどを見てみる。
VPoEが2018年度に担っていた動きをチームとして対応できるようにするためにCTO室が設立されました。
詳細は不明
CTO室は2019年5月にできました。前身はモンストの開発・運用をしていた事業本部内にて、複数のサービスに関わるエンジニアを集めてできた開発本部の下部組織でした。現在は事業部を横断した開発者支援や、事業部内のサービス、プロジェクトに入って個別支援を行っています。
CTO室は主に以下の4つのミッションがあります。 1つ目の「サービス技術の設計、開発、保守の研究および開発」というミッションでは、最新の技術動向を追跡し、それを調査・検証しています。これにより、サービスの価値向上をリードする役割を果たしています。 次に、「ものづくり人材の育成」というミッションは、社内エンジニアの育成に重点を置いていますが、同時に渋谷区などの高等専修学校への教育サポート活動も行っています。 「QAの改善活動」は、サービス品質の向上だけでなく、各事業部に継続的な改善プロセスや手順を提供し、その実践を支援することをミッションとしています。 最後に、「データのKPI設計や分析の支援」では、データ活用に関する考え方やアプローチを企業全体に展開しています。KPI設計やデータ分析を通じて、サービスのパフォーマンスを評価し、事業部や経営層の意思決定をサポートしています。
事業会社ですから、個々の機能のリリースや突発的なパフォーマンスの改善などのほうが、どうしても優先されます。その都度いろいろなチームにヘルプとして呼ばれる、というような状況でした。正直、それだと横軸の改善作業は全然進まない状態だったんですね。ですから、いわゆる全社的な改善作業をするチームを切り分けようというのが、CTOの松下さんが、これまでのプロダクト本部とは別にCTO室という組織を立ち上げた意図だと思います。
CTO室の役割は、課題を自分たちで見つけてきて、それを改善することです。課題はたくさんあるので、できることから手をつけていくしかありません。その際に意識しているのは、「カオナビ」の開発効率が上がって、より顧客に対する価値提供をスムーズに行えるようになることです。逆に言えば、そこさえブレなければ手法は何でもいい。
不明
CTO室では、インフラやセキュリティなどのいわゆる共通基盤や事業部のミッション外ではあるが会社として必要な技術領域の取り組みを行なっています。
CTO就任とともに発足?
簡単に言えば、CTOの想いを実現させる部署です。CTOが就任した後、弊社ではDMM Tech Visionを発表しています。私たちがやるべきことは、その実現です。そのために、現在は3つのチームに分かれて活動をしています。 まずは、制度設計やブランディングを担当するエバンジェリストチーム。技術のスペシャリストで結成されたチームで、人事と接点を持ちながらエンジニアのスキルアップを支援したり、技術広報をしたりと、対外的な活動も行います。 そのほかに、事業支援チームと技術支援チームがあります。事業支援チームは、読んで字のごとく事業部に対して技術的な側面から事業支援を行う組織です。コードを書くなど実務的なサポートもしますが、事業成長に貢献することをミッションに置いており、組織開発からシステム開発までなんでもこなします。 技術支援チームの役割は、社内エンジニア向けの共有ツールを開発したり、自社運用していたシステムのクラウド化を推進したり、全社単位での技術支援を行うことです。基本的にはこの3チームが力を合わせ、DMM.comのテックカンパニー化を推進しています。
レバテックにおけるシステム・データの課題を解決をリードしていくため
ちなみに、CTO室設立の背景として、ベルフェイスの開発環境がお世辞にも整ったものではなかったということが挙げられます。上記の3点に取り組み、CTOや開発メンバーがやりたいと思ったことを実現するための環境づくりを行うことで、プロダクト作りを推進しています。
端的に言うと以下の3つに取り組んでいる組織です。 1.システムの安定稼働 2.開発プロセスの健全化 3.無理無駄の撲滅 総じてリーンでアジャイルな開発体制を確立し、QCDFを向上させることに注力しています。
僕がCTOになって仕事を抱えすぎて辛そうにしているのを見て、社長の佐藤が、heyの中にいるCTO経験者を集めてチームにしてみてはどうかと提案してくれました。どの会社にも、会社を横断した課題を解決する箱があるものです。heyの場合はプロダクトごとに組織がわかれていますが、目指していることはひとつ。横断だからできることや、個別のチームだけでは解決できないことをCTO室の裁量で解決するためにこのチームができました。
事業的に目指すところがある程度わかっていて、未来の目標も共有できているメンバーが集まって、さまざまなことを解決しています。例えば、組織マネジメントの課題として、今の組織の形をどうしたらもっと良くできるか、などです。他にも、採用基準、評価、査定、異動など。組織を運営している上で起こる、事務的でもあり、難しい判断が必要なことを解決しています。 また、技術的に横断でやったほうがいい仕事もここで話し合っています。モバイルアプリや、インフラなどのテクノロジーをどう考えるか、などです。
DB分割のためのチームを作ったことがきっかけでCTO室という組織を作りました。
全社的な、あるいは複数のサービスにまたがるような技術的負債の返済を主なミッションとした組織です。各サービスチームの意思決定はどうしても個別最適な意思決定になりがちなので、時には全体最適で意思決定して取り組む必要がある課題も出てきます。 私はCTO室を作って以来、全体最適の取り組みにアサインするべきリソースをCTO室で確保するようにしていて、タイミングによって増減はありますが、おおむね10-15%ぐらいのエンジニアにCTO室で働いてもらってます。 各サービスの開発チームにアサインされているエンジニアの人事権は私にはありませんが、CTO室のリソースは全社的な課題にアサインしたり、その時に最もフォローが必要なサービス開発チームを支援したり等の調整弁になっていて、リソース調整のスピードと柔軟性を高めることに役立っています。
各社のCTO室について設立の背景やミッションについて調べてみた。 当たり前に各社様々な目的や背景、ミッションを持っているが大枠では「全社横断で解決すべき課題を解決するための組織」という部分が共通しているのかなと思った。
これらの調べてた内容を元に自組織の運営に活かしていきたい。
油断していたら2022年の振り返りをすっ飛ばし、2023年の振り返り記事を上げる前に年を越してしまった。 ここ数年は個人的にかなり濃密な日々となっているのでしっかり振り返って、来年の抱負も掲げてしっかりやっていきたい。
過去の振り返りとか見ていると、かなり忘れている出来事も多く、そして掲げた目標もほぼ達成できてなくてなんて適当なやつなんだと笑えてくるが日々楽しく幸せな人生を過ごせているし、奥さんとも仲良しだし、着実に成長も実感出来ているし、2023年も大いに飛躍出来た一年となった(?)のでヨシ!!!
しかし自分は本当にある意味場当たり的に一生懸命生きている運の良いだけの人間なのだなぁと痛感し、持たざる者であることを自覚し、これからもできる範囲で頑張らないといけないなぁ、という気持ち(ガンバレ
まず仕事、登壇&コミュニティ活動という切り口で出来事やイベントを羅列し、それぞれ印象的な出来事を中心に深掘りながら最後に総括という形で全体を振り返っていこうと思います!
年始早々(1/3〜1/9)CES視察と称した自身初となるアメリカを出張という形で訪れることになった。 これも初となるホノルルで10時間以上あるトランジットを正月からヨットで回遊しながら休憩ポイントでは船上でハンバーガーを作って食べたり海で泳いだりして満喫し、そこからLAへ行きグランドキャニオンのツアーへ参加したり、戻ってからは初カジノで$1,100勝ちからの$500負けでフィニッシュしたり、CESへも参加したり、シルクドソレイユの「O」を観覧したり、フェニックスではWaymo、サンフランシスコではGMクルーズのレベル4自動運転による無人タクシーを体験したりと本当に色々と貴重な体験をすることが出来た。
また2023年はIT健保のレストラン巡りと保養施設でのワーケーションがQOLを高めてくれた。特にIT健保寿司として名高い「一新」や和食レストラン「木都里亭」とチーム合宿と称して行ったトスラブ箱根和奏林はめちゃくちゃ良かった。IT健保加入してるエンジニア諸氏におかれては是非訪れてほしい。
IT健保の素晴らしいレストラン、保養施設について、また活用戦略については前職のマイメンが記事を書いてくれているのでこちらも是非参考にしてほしい。
2023年最大のイベントは何と言ってもやはり転職だった。
前述の通り、8月にイオンスマートテクノロジー社へCTOのリファラルで転職した。
SREとしてはチームの状態を整えるために詳しくは書けないが色々と精神をすり減らしながら奔走した5ヶ月だった。 中々の苦行だったが種まきを何とか年内に終わらせることが出来たので、2024年はしっかりと成果を上げていきたい。
詳細が気になる方は飲みに誘っていただければベラベラ喋ると思いますのでお誘いお待ちしております🍺
また、中に入ってみて内部への働きかけより外部からのプレゼンスを高めることが色々と近道だと判断し、テックブログやDevRelチームの立ち上げ、アドベントカレンダーの実施などにチャレンジをした結果、これらの活動を通じてエンジニア組織としてのプレゼンスをかなり高めることができた。 特にDevRelチームは増幅拡大の装置としては申し分ない機能を持たせることができたので、今年は採用活動と組織改革を本格的に推進していき強固な地盤固めを行う一年としていきたい。
関連記事は以下
俺の役割 is 何?という風に感じられる方もいると思うが、前向きな言い方をすると必要なことであれば何でもやれるフェーズであるということです。
2023年はコミュニティ活動を通じて色々な人と接点を持ったり仲を深める事ができた。 今までコミュニティに関わることで人生が変わった、というような人の話を聞く事がよくあったが、昨年はまさに自分の人生も様々なコミュニティを通じて拡張されていく感覚があった。 今では自分の言葉として「コミュニティに関わることで人生が変わった」と言えるようになったと思う。
ハイライトとしてはCloudflare Meetup Naganoを主催(?)し、長野の技術コミュニティの方々と繋がることが出来たり、NRUG SRE支部メンバーで共著で書籍を出版したり、JAWS-UG コンテナ支部 #24 ecspresso MeetUpでは敬愛するfujiwaraさんやsongmuさんと一緒にお酒を飲んだり、Cloud in the Camp 勝浦で色々な人と交流できたあたりだと思う。
また例年よりも多くの様々なイベント(登壇や主催以外の)へオンライン、オフライン問わず参加したような気がする。
引き続き自分の人生をより豊かにし、学びを得るため、また還元するためにも積極的にコミュニティ活動やイベントへ参加して行こうと思う。
2022年もそうだったが、2023年も本当にイベントや変化の多い一年になった。
なんと言っても転職したことによる変化が一番大きかったが、仕事的にはこの一年で初めてアメリカと中国へ海外出張に行ったり、本を出版したり、ワーケーションと称して伝説のトスラブ箱根和奏林に行ったり(マジ最高だった)、プライベートでは千葉と四国へ家族旅行したり、消防団やサッカーのコーチを始めたり、マイカーを購入したりと人生においても記憶に残るであろう良い経験となるイベントが目白押しでとても良い一年となった。
転職して大変な時期もあったりしたが、あの手この手でなんとか光が見える状況にはなって来たので今年は方針策定して大きな成果を創出していきたい。
ここ数年は仕事のみならず自分の戦略・戦術がハマることが多いのだがディテールが甘かったり大雑把な部分は散見されるのでそういった部分は改善していき、より良い人生を歩めていけるように精進していきたい。
個人的な今年の抱負としては以下についてそれぞれ習慣化のための施策を遂行できるように頑張っていきたい。 2024年は継続力をキーワードに習慣化を進めていきたい(自信ないけど)
全体の共通施策として「毎週日曜に振り返りと計画を行う」ことを継続していきたい。
主に技術書が対象になると思うが、以下のような施策をしっかりと遂行していきたい。
後述するフォーカスすべき技術領域の学習にも関係するが、年間でどれぐらい何を読むかをある程度計画し、読み終わったら書評を書くなどアウトプットとセットで読むようにする。 また、会社のメンバーを巻き込んで輪読会を実施しチーミングも兼ねて相互で学習する仕組みを作り上げる。
読書管理にはブクログを活用するようにする。
自分は今までなんでもできるようになりたいという気持ちが強く、学習対象もかなり散漫だったが今後は明確に以下の領域に絞り、Infra/DevOps/SRE/PlatformEngineering領域を強みとしたエンジニアとしてしっかり市場価値も上げていき、会社・事業にもコミットしていきたい。
どのように学習していくかは基本的にはインプットとアウトプットになるわけだが、その主軸は以下だ。
すでに今年もデブサミへの登壇も決まっていたり、TiUGやAEON Tech Talkなどのイベント開催も予定しているのでそれらのイベントやSRE Next、PlatformEngineeringMeetup、CNDTなど大きなカンファレンスでの登壇にもどんどん挑戦していきたい。
そして今年はISUCONにも挑戦したい!!
月並みだが以下のアプリでの学習を毎日やる!
とりあえず意識しながら無理せずという感じで頑張りたい。
とまぁ、こんな感じで雑に振り返ってみたり抱負を述べたりしましたが意味があるかどうかは今後の自分次第だけど良い機会にはなったので引き続き今を一生懸命生きつつ、ほどほどに頑張りたいと思います!
2月には納車、6月には4人目となる子供が産まれる予定(!?)なので今年もイベント目白押しな予感!!
色々教えてもらったので備忘録
製品欄のAzure Kubernetes Serviceにチェックをいれた状態のURL
非推奨のAPIの使用を確認できるKubernetes API deprecationsが便利そう
AKS は、すべてのクラスターと顧客に影響を与える一連の修正プログラム、および機能とコンポーネントの更新プログラムを毎週リリースします。 ただし、これらのリリースは、Azure の安全なデプロイ プラクティス (SDP) により、最初の出荷時点からすべてのリージョンに展開されるまで最大 2 週間かかることがあります。 お客様のリージョンが特定の AKS リリースの対象となっている場合にそれを把握することが重要であり、AKS リリース トラッカーは、これらの詳細をバージョンとリージョン別にリアルタイムで提供します。
定期的に読むと良さそう
日本語化されているものがオススメ
MS真壁さん作
とりあえずAKSのセットアップができたのでArgoCDをデプロイしてみる
とはいえ基本的には公式に記載されていることをするだけでデプロイできた(k8sすごい)
$ kubectl create namespace argocd $ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
お手軽に接続して確認するためにPortFowardingを実施
$ kubectl port-forward svc/argocd-server -n argocd 8080:443 Forwarding from 127.0.0.1:8080 -> 8080 Forwarding from [::1]:8080 -> 8080
https://localhost:8080/ へ接続するとArgoCDのログイン画面が表示されることを確認
argocd
コマンドで初期パスワードを取得する
$ argocd admin initial-password -n argocd XXXXXXXXXXXXXXX ←ここに初期パスワードが表示される This password must be only used for first time login. We strongly recommend you update the password using `argocd account update-password`.
先ほど取得したパスワードとadmin
ユーザーを入力してログインできた
SRE文脈な書籍が増えてきたので読んでおくと良さそうなやつを主に以下の分類でピックアップしておく
SRE文脈とは?という感じではあるがSREというロールでいるのであればこのあたりは一通り読んでおきたい(読んでいるとは言っていない)
アーキテクチャ関連書籍はこちらにまとめたのでどぞ blog.tocyuki.com
ここ2〜3年で検証機なんだかんだ6台ほど新しいMacをセットアップすることがあり、Macの初期セットアップ大体同じことやってるのでなんとなくメモしておく
以下設定する
自分は現在のデフォルトのスクロール方向とは逆に慣れてしまっているのでまずここを直します
これもめちゃくちゃ便利なので必ず有効化してるんですが微妙に分かりづらい場所に設定が会って毎回一瞬「あれ?どこだっけ?」となるやつ
caps lock
を^
(control)へ変更使うことない&HHKBのキー配置に合わせて変更
キーボード、スクロールなどなどの感度系を最速にしておく
dotfilesリポジトリを運用しているのでこいつをgit clone
してタスクランナーであるMakefile
で諸々実行して必要なアプリや設定をする
自分はシェルにtmux
&fish
を使っている使ってるので設定していく
dotfiles
&ansible
による構成管理をしているため結構楽にセットアップできてるので良きだなぁと改めて思うなどした
とりあえずTerraformでAKS構築して手元からkubectl cluster-infoできるところまできた。
— 𝕋𝕠𝕔𝕪𝕦𝕜𝕚 𝕏 (@Tocyuki) August 15, 2023
というわけで(?)Azureなんもわからんマンなのでazure-cli
とkubectl
で手元から構築したKubernetes Clusterへの接続方法をメモしておきます。
$ az login
サブスクリプション一覧を表示して対象となるサブスクリプション名 or サブスクリプションIDを取得
$ az account list -o table
取得したサブスクリプション名 or サブスクリプションIDを指定してサブスクリプションを設定
$ az account set --subscription <サブスクリプション名 or サブスクリプションID>
AKSクラスタ名とリソースグループ名を取得
$ az aks list --output table
取得したAKSクラスタ名とリソースグループ名を使って認証する
$ az aks get-credentials --resource-group <resource_group_name> --name <cluster_name>
あとは各種kubectl
コマンドを実行するだけなので試しにNginxでもデプロイしてみる
$ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
Podが起動してくるか確認
$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-deployment-cbdccf466-44bws 1/1 Running 0 69s nginx-deployment-cbdccf466-5lr6d 1/1 Running 0 69s nginx-deployment-cbdccf466-cl2l6 1/1 Running 0 69s
よし、起動した
色々なアーキテクチャを勉強するにあたり、とりあえずこのあたりは読んでおくと良さそうという書籍をピックアップ(全部読んだとは言っていない)
JetBrains系IDEのIdeaVimプラグインでNERDTreeが使えただと!??https://t.co/lTOD6vFyM0
— 𝕋𝕠𝕔𝕪𝕦𝕜𝕚 𝕏 (@Tocyuki) July 26, 2023
というわけで普段はIntellijIDEAをメインに使っているんですが、元々Vimをメインで使っていたのでもちろんIdeaVimプラグインは使っていました。
ファイラーの扱いだけちょっとなーと思っていたんですが、使っているキーボードのカスタムキーバインドでなんとかやっていたところNERDTreeのキーバインド使えるんかいとなったので導入したのでそのメモ書きとして残しておきます。
基本的には以下に記載があるので要参照。
コマンド | 説明 |
---|---|
:NERDTree |
カレントディレクトリのツリー表示を開く |
:NERDTreeFocus |
NERDTreeウィンドウにフォーカスを移動する |
:NERDTreeToggle |
NERDTreeウィンドウの表示と非表示を切り替える |
:NERDTreeClose |
NERDTreeウィンドウを閉じる |
:NERDTreeFind |
現在開いているファイルをNERDTreeウィンドウ内で見つける |
:NERDTreeRefreshRoot |
NERDTreeウィンドウのルートディレクトリを再描画する |
キー | 説明 | マップ設定 |
---|---|---|
o |
ファイル、ディレクトリ、ブックマークを開く | g:NERDTreeMapActivateNode |
go |
選択したファイルを開くが、カーソルはNERDTreeに残る | g:NERDTreeMapPreview |
t |
選択したノード/ブックマークを新しいタブで開く | g:NERDTreeMapOpenInTab |
T |
't'と同じ操作を行うが、現在のタブにフォーカスを保つ | g:NERDTreeMapOpenInTabSilent |
i |
選択したファイルを分割ウィンドウで開く | g:NERDTreeMapOpenSplit |
gi |
'i'と同じ操作を行うが、カーソルはNERDTreeに残る | g:NERDTreeMapPreviewSplit |
s |
選択したファイルを新しいvsplitで開く | g:NERDTreeMapOpenVSplit |
gs |
's'と同じ操作を行うが、カーソルはNERDTreeに残る | g:NERDTreeMapPreviewVSplit |
O |
選択したディレクトリを再帰的に開く | g:NERDTreeMapOpenRecursively |
x |
現在のノードの親を閉じる | g:NERDTreeMapCloseDir |
X |
現在のノードのすべての子を再帰的に閉じる | g:NERDTreeMapCloseChildren |
P |
ルートノードにジャンプする | g:NERDTreeMapJumpRoot |
p |
現在のノードの親にジャンプする | g:NERDTreeMapJumpParent |
K |
現在のツリーの深さでディレクトリの内部にジャンプする | g:NERDTreeMapJumpFirstChild |
J |
現在のツリーの深さでディレクトリの内部にジャンプする | g:NERDTreeMapJumpLastChild |
<C-J> |
現在の階層から次の同階層にジャンプする | g:NERDTreeMapJumpNextSibling |
<C-K> |
現在の階層から前の同階層にジャンプする | g:NERDTreeMapJumpPrevSibling |
r |
現在のディレクトリを再帰的に更新する | g:NERDTreeMapRefresh |
R |
現在のルートを再帰的に更新する | g:NERDTreeMapRefreshRoot |
m |
NERDTreeのメニューを表示する(右クリックしたときと同じ) | g:NERDTreeMapMenu |
q |
NERDTreeウィンドウを閉じる | g:NERDTreeMapQuit |
A |
NERDTreeウィンドウのズーム(最大化/最小化)を切り替える | g:NERDTreeMapToggleZoom |
ファイラーの扱いがずっともやもやしていたのでこれでより快適なIntellijIDEAライフを送れそう🫶
N億年ぶりにディスク拡張したので備忘録
AWSのマネコンから実施
現状を確認
ubuntu@ip-10-0-8-197:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 2.0G 0 2.0G 0% /dev tmpfs 393M 792K 393M 1% /run /dev/xvda1 7.6G 1.3G 6.3G 18% / tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup /dev/xvda15 105M 5.2M 100M 5% /boot/efi /dev/loop0 54M 54M 0 100% /snap/snapd/19122 /dev/loop1 56M 56M 0 100% /snap/core18/2751 /dev/loop2 25M 25M 0 100% /snap/amazon-ssm-agent/6563 tmpfs 393M 0 393M 0% /run/user/1000
grwpart
コマンドでOSにボリュームを認識させる
ubuntu@ip-10-0-8-197:~$ sudo growpart /dev/xvda 1 CHANGED: partition=1 start=227328 old: size=16549855 end=16777183 new: size=167544799,end=167772127
resize2fs
ファイルシステムを拡張する
ubuntu@ip-10-0-8-197:~$ sudo resize2fs /dev/xvda1 resize2fs 1.44.1 (24-Mar-2018) Filesystem at /dev/xvda1 is mounted on /; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 10 The filesystem on /dev/xvda1 is now 20943099 (4k) blocks long.
ディスクサイズが拡張されたことを確認
ubuntu@ip-10-0-8-197:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 2.0G 0 2.0G 0% /dev tmpfs 393M 792K 393M 1% /run /dev/xvda1 78G 1.3G 77G 2% / tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup /dev/xvda15 105M 5.2M 100M 5% /boot/efi /dev/loop0 54M 54M 0 100% /snap/snapd/19122 /dev/loop1 56M 56M 0 100% /snap/core18/2751 /dev/loop2 25M 25M 0 100% /snap/amazon-ssm-agent/6563 tmpfs 393M 0 393M 0% /run/user/1000
ここ数年Wordpressから逃げられない感じ笑う
— 𝕋𝕠𝕔𝕪𝕦𝕜𝕚 𝕏 (@Tocyuki) 2021年10月5日
というわけで、何度現場を移ってもWordpressから逃げられないんですよこれが。
久しぶりに1から構築するということでEFSの速度改善もしたし、使ってみるかぁという感じでやってみました。
しかし構築したもののCSSが適用されず微妙にハマり以下のQiita記事を見て膝からがっくり落ちましたよ。。。
とりあえずfastcgi_param
にHTTPS on
を渡して対応しておしまい。
あとはRedisとS3を準備しておけばOKかな〜。
terraform plan
実行して問題ないことを確認して、数秒後に再実行したらこれですよ。。。
$ terraform plan Creating terraform-aws_terraform_run ... done Acquiring state lock. This may take a few moments... ╷ │ Error: Error acquiring the state lock │ │ Error message: ConditionalCheckFailedException: The conditional request failed │ Lock Info: │ ID: 0bab5536-fbfb-8878-012a-1696f30d9c96 │ Path: dev-tfstate-XXXXXXXXXXXX/dev.tfstate │ Operation: OperationTypeApply │ Who: root@XXXXXXXXXXXX │ Version: 1.0.0 │ Created: 2021-10-26 04:58:02.9271349 +0000 UTC │ Info: │ │ │ Terraform acquires a state lock to protect the state from being written │ by multiple users at the same time. Please resolve the issue above and try │ again. For most commands, you can disable locking with the "-lock=false" │ flag, but this is not recommended. ╵
はいはい、強制解除強制解除ぐらいのノリで、ツイートしたりしちゃうぐらい呑気な感じでした。
force-unlockするの何気に初めてかも。https://t.co/d8XJkejBil
— 𝕋𝕠𝕔𝕪𝕦𝕜𝕚 𝕏 (@Tocyuki) 2021年10月26日
$ terraform force-unlock 0bab5536-fbfb-8878-012a-1696f30d9c96 Creating terraform-aws_terraform_run ... done Do you really want to force-unlock? Terraform will remove the lock on the remote state. This will allow local Terraform commands to modify this state, even though it may be still be in use. Only 'yes' will be accepted to confirm. Enter a value: yes Terraform state has been successfully unlocked! The state has been unlocked, and Terraform commands should now be able to obtain a new lock on the remote state.
はい、治ったーと思ったら、以下のエラーでplanもapplyもできなくなってしまった。
╷ │ Error: Error loading state: state data in S3 does not have the expected content. │ │ This may be caused by unusually long delays in S3 processing a previous state │ update. Please wait for a minute or two and try again. If this problem │ persists, and neither S3 nor DynamoDB are experiencing an outage, you may need │ to manually verify the remote state and update the Digest value stored in the │ DynamoDB table to the following value: 755b517c310c11f04b3dfef86988ffce │ │ │ ╵
上記のエラーで出ているDigest値と異なっていることが確認できた。
755b517c310c11f04b3dfef86988ffce
48f5307177582df2355d9b55f7a5105b
$ aws dynamodb scan --table-name dev-tfstate-lock --profile dev { "Items": [ { "Digest": { "S": "48f5307177582df2355d9b55f7a5105b" }, "LockID": { "S": "dev-tfstate-XXXXXXXXXXXX/dev.tfstate-md5" } } ], "Count": 1, "ScannedCount": 1, "ConsumedCapacity": null }
aws cliで直接DynamoDBのDigestを更新してみる
$ aws dynamodb update-item --table-name dev-tfstate-lock --key '{"LockID": {"S": "dev-tfstate-xxxxxxxxxxxx/dev.tfstate-md5"}}' --attribute-updates '{"Digest": {"Value": {"S": "755b517c310c11f04b3dfef86988ffce"},"Action": "PUT"}}' --return-values UPDATED_NEW --profile dev | jq '.Attributes.RuleSetVersion.S'
お、ちゃんと変わってる
$ aws dynamodb scan --table-name dev-tfstate-lock --profile dev { "Items": [ { "Digest": { "S": "755b517c310c11f04b3dfef86988ffce" }, "LockID": { "S": "dev-tfstate/dev.tfstate-md5" } } ], "Count": 1, "ScannedCount": 1, "ConsumedCapacity": null }
再度、コマンド実行してみたところ、plan
もapply
も問題なく実行できるようになりました!