Tocyukiのブログ

ギターと柔術とプログラミングが好き!

他社SREチームのミッションについて調べてみる

現職のSREチームのMVVを検討し始めてるので他社のMVVについて調べてみる

NewsPicks

note.com

NewsPicks SREチームのミッション

SmartShopping

tech.smartshopping.co.jp

  • ミッション
    • 日常を革新するプロダクトが走り続けるために、整備された道とガードレールを作り改善していく
  • ビジョン
    • 自律して信頼性の高いプロダクトを作り続けられるスマートな開発組織の実現
  • バリュー
    • Bold and Flexible
    • Automation
    • One for All
    • Data Driven
    • Proactive

dely

tech.dely.jp

delyが持つ熱量と幸せをできるだけ多くの人に届けられるように、プロダクトの価値最大化をシステム運用において実現する。 その過程において最善の選択が何であるかを考え、システムの設計と運用を改善し続ける。

『スタディサプリENGLISH』 SREグループ

blog.recruit.co.jp

  • ミッション
    • 自分たちの持つ専門性を活かし、開発者が開発に集中して最大限の力を発揮できる状態を目指す
  • ビジョン
    • 品質も効率もあきらめない!イケてる環境を作る

『スタディサプリ小中高』 SREグループ

blog.studysapuri.jp

  • Mission
    • 自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフォームと文化を作る
  • Vision
    • 最高の学習プロダクトを作り続けられる開発組織の実現
  • Values
    • Fail smart
    • Learning
    • Borderless
    • Metrics-driven

STORES

product.st.inc

ユーザーにたくさんの価値を素早く提供できるようにしながら、事業の成長を阻害する要因を取り除く

レバレジーズ

tech.leverages.jp

SRE化を通して、Developer Experienceの改善、事業の拡大への対応、お客様に信頼されるサービスの提供を実現する

Sansan BillOne

speakerdeck.com

Mission/Vision

eureka

medium.com

  • Mission
    • SREプラクティスを開発組織にインストールしていく
  • Vision
    • 自律的にリライアビリティとアジリティを両立するプロダクト開発組織の実現
  • Values
    • Metrics First
      • 主観ではなく、計測した定量的な指標に基づいて意思決定する
    • Draw a Blueprint
      • 物事のAsIs — ToBeを自ら描いて自ら実現していく
    • No Blame
      • 非難をしない、問題を回避したり最小化したり隠蔽するのではなく問題を明らかにしていく
    • Learning Animal
      • 現状に甘んじず、ToBeを描くために貪欲にインプットし続けていく
    • Change Agent
      • 組織に忖度せず、必要なことについて議論を恐れず、やるべきことは自らが主導となって働きかける

mercari Microservice SREチーム

engineering.mercari.com

  • マイクロサービスチーム特有の事情に合わせた信頼性向上のサポートを行うEmbedded SREs
  • 組織全体にSREプラクティスを広めていく
  • Platformチームが開発するマイクロサービス基盤の新しい機能の導入を支援する

M3

www.m3tech.blog

  • エムスリーが提供するサービスのシステム基盤について、現在から将来に渡って高い信頼性やセキュリティを保った管理・運用を行うことで、顧客が安心して快適にサービスを利用できるようにする。
  • ビジネス要求や環境の変化に素早く柔軟に対応できるようなシステム基盤を実現し、スケール可能なチームづくりとその維持を行う。

カヤック

明確なミッションが書かれているわけではないが参考になるので貼っておく

techblog.kayac.com

色々な会社のCTO室設立の背景やミッションについて調べてみる

今所属している会社にもCTO室があるが、他の会社がどのような背景・目的・役割でCTO室を設けているのか気になったので調べてみる。 インターネットで雑に検索して出て来たものをいくつかピックアップし、設立の背景・目的、ミッションなどで共通項があるかなどを見てみる。

ZOZO

qiita.com

設立の背景・目的

VPoEが2018年度に担っていた動きをチームとして対応できるようにするためにCTO室が設立されました。

ミッション

ZOZO CTO室ミッション

MIXI

mixil.mixi.co.jp

設立の背景・目的

詳細は不明

CTO室は2019年5月にできました。前身はモンストの開発・運用をしていた事業本部内にて、複数のサービスに関わるエンジニアを集めてできた開発本部の下部組織でした。現在は事業部を横断した開発者支援や、事業部内のサービス、プロジェクトに入って個別支援を行っています。

ミッション

CTO室は主に以下の4つのミッションがあります。 1つ目の「サービス技術の設計、開発、保守の研究および開発」というミッションでは、最新の技術動向を追跡し、それを調査・検証しています。これにより、サービスの価値向上をリードする役割を果たしています。 次に、「ものづくり人材の育成」というミッションは、社内エンジニアの育成に重点を置いていますが、同時に渋谷区などの高等専修学校への教育サポート活動も行っています。 「QAの改善活動」は、サービス品質の向上だけでなく、各事業部に継続的な改善プロセスや手順を提供し、その実践を支援することをミッションとしています。 最後に、「データのKPI設計や分析の支援」では、データ活用に関する考え方やアプローチを企業全体に展開しています。KPI設計やデータ分析を通じて、サービスのパフォーマンスを評価し、事業部や経営層の意思決定をサポートしています。

KAONAVI

vivivi.kaonavi.jp

設立の背景・目的

事業会社ですから、個々の機能のリリースや突発的なパフォーマンスの改善などのほうが、どうしても優先されます。その都度いろいろなチームにヘルプとして呼ばれる、というような状況でした。正直、それだと横軸の改善作業は全然進まない状態だったんですね。ですから、いわゆる全社的な改善作業をするチームを切り分けようというのが、CTOの松下さんが、これまでのプロダクト本部とは別にCTO室という組織を立ち上げた意図だと思います。

ミッション

CTO室の役割は、課題を自分たちで見つけてきて、それを改善することです。課題はたくさんあるので、できることから手をつけていくしかありません。その際に意識しているのは、「カオナビ」の開発効率が上がって、より顧客に対する価値提供をスムーズに行えるようになることです。逆に言えば、そこさえブレなければ手法は何でもいい。

YOUTRUST

tech.youtrust.co.jp

設立の背景・目的

不明

ミッション

CTO室では、インフラやセキュリティなどのいわゆる共通基盤や事業部のミッション外ではあるが会社として必要な技術領域の取り組みを行なっています。

DMM

inside.dmm.com

設立の背景・目的

CTO就任とともに発足?

ミッション

簡単に言えば、CTOの想いを実現させる部署です。CTOが就任した後、弊社ではDMM Tech Visionを発表しています。私たちがやるべきことは、その実現です。そのために、現在は3つのチームに分かれて活動をしています。 まずは、制度設計やブランディングを担当するエバンジェリストチーム。技術のスペシャリストで結成されたチームで、人事と接点を持ちながらエンジニアのスキルアップを支援したり、技術広報をしたりと、対外的な活動も行います。 そのほかに、事業支援チームと技術支援チームがあります。事業支援チームは、読んで字のごとく事業部に対して技術的な側面から事業支援を行う組織です。コードを書くなど実務的なサポートもしますが、事業成長に貢献することをミッションに置いており、組織開発からシステム開発までなんでもこなします。 技術支援チームの役割は、社内エンジニア向けの共有ツールを開発したり、自社運用していたシステムのクラウド化を推進したり、全社単位での技術支援を行うことです。基本的にはこの3チームが力を合わせ、DMM.comのテックカンパニー化を推進しています。

レバテック

tech.leverages.jp

設立の背景・目的

レバテックにおけるシステム・データの課題を解決をリードしていくため

ミッション

レバテックCTO室のミッション

ベルフェイス

bs.bell-face.com

設立の背景・目的

ちなみに、CTO室設立の背景として、ベルフェイスの開発環境がお世辞にも整ったものではなかったということが挙げられます。上記の3点に取り組み、CTOや開発メンバーがやりたいと思ったことを実現するための環境づくりを行うことで、プロダクト作りを推進しています。

ミッション

端的に言うと以下の3つに取り組んでいる組織です。  1.システムの安定稼働  2.開発プロセスの健全化  3.無理無駄の撲滅  総じてリーンでアジャイルな開発体制を確立し、QCDFを向上させることに注力しています。

Hey

people.st.inc

設立の背景・目的

僕がCTOになって仕事を抱えすぎて辛そうにしているのを見て、社長の佐藤が、heyの中にいるCTO経験者を集めてチームにしてみてはどうかと提案してくれました。どの会社にも、会社を横断した課題を解決する箱があるものです。heyの場合はプロダクトごとに組織がわかれていますが、目指していることはひとつ。横断だからできることや、個別のチームだけでは解決できないことをCTO室の裁量で解決するためにこのチームができました。

ミッション

事業的に目指すところがある程度わかっていて、未来の目標も共有できているメンバーが集まって、さまざまなことを解決しています。例えば、組織マネジメントの課題として、今の組織の形をどうしたらもっと良くできるか、などです。他にも、採用基準、評価、査定、異動など。組織を運営している上で起こる、事務的でもあり、難しい判断が必要なことを解決しています。 また、技術的に横断でやったほうがいい仕事もここで話し合っています。モバイルアプリや、インフラなどのテクノロジーをどう考えるか、などです。

マネーフォワード

moneyforward-dev.jp

設立の背景・目的

DB分割のためのチームを作ったことがきっかけでCTO室という組織を作りました。

ミッション

全社的な、あるいは複数のサービスにまたがるような技術的負債の返済を主なミッションとした組織です。各サービスチームの意思決定はどうしても個別最適な意思決定になりがちなので、時には全体最適で意思決定して取り組む必要がある課題も出てきます。 私はCTO室を作って以来、全体最適の取り組みにアサインするべきリソースをCTO室で確保するようにしていて、タイミングによって増減はありますが、おおむね10-15%ぐらいのエンジニアにCTO室で働いてもらってます。 各サービスの開発チームにアサインされているエンジニアの人事権は私にはありませんが、CTO室のリソースは全社的な課題にアサインしたり、その時に最もフォローが必要なサービス開発チームを支援したり等の調整弁になっていて、リソース調整のスピードと柔軟性を高めることに役立っています。

各社のCTO室設立の背景・目的まとめ

  • VPoE, CTOの負担軽減
  • 全社横断な課題解決組織として発足

各社のCTO室ミッションまとめ

  • ZOZO
    • 全社における技術的な戦略策定および、エンジニア組織強化のための施策の推進
  • MIXI
    • サービス技術の設計、開発、保守の研究および開発
    • ものづくり人材の育成
    • QAの改善活動
    • データのKPI設計や分析の支援
  • KAONAVI
    • 開発効率が上がって、より顧客に対する価値提供をスムーズに行えるようになること
  • YOUTRUST
    • インフラやセキュリティなどのいわゆる共通基盤や事業部のミッション外ではあるが会社として必要な技術領域の取り組み
  • DMM
    • CTOの想いを実現させる、DMM.comのテックカンパニー化を推進
  • レバテック
    • 事業拡大に伴い、既存の複数サービスとこれから立ち上がるサービス含めて総合的にアーキテクチャや設計を考え、開発や事業をリードしていくための組織
  • ベルフェイス
    • システムの安定稼働
    • 開発プロセスの健全化
    • 無理無駄の撲滅
    • 総じてリーンでアジャイルな開発体制を確立し、QCDFを向上させることに注力
  • Hey
    • 事業的に目指すところがある程度わかっていて、未来の目標も共有できているメンバーが集まって、さまざまなことを解決
    • 採用基準、評価、査定、異動など組織を運営している上で起こる、事務的でもあり、難しい判断が必要なことを解決
    • 技術的に横断でやったほうがいい仕事もここで話し合っています。モバイルアプリや、インフラなどのテクノロジーをどう考えるか
  • マネーフォワード
    • 全社的な、あるいは複数のサービスにまたがるような技術的負債の返済を主なミッションとした組織

まとめ

各社のCTO室について設立の背景やミッションについて調べてみた。 当たり前に各社様々な目的や背景、ミッションを持っているが大枠では「全社横断で解決すべき課題を解決するための組織」という部分が共通しているのかなと思った。

これらの調べてた内容を元に自組織の運営に活かしていきたい。

2023年の振り返りと2024年の抱負

油断していたら2022年の振り返りをすっ飛ばし、2023年の振り返り記事を上げる前に年を越してしまった。 ここ数年は個人的にかなり濃密な日々となっているのでしっかり振り返って、来年の抱負も掲げてしっかりやっていきたい。

過去の振り返りとか見ていると、かなり忘れている出来事も多く、そして掲げた目標もほぼ達成できてなくてなんて適当なやつなんだと笑えてくるが日々楽しく幸せな人生を過ごせているし、奥さんとも仲良しだし、着実に成長も実感出来ているし、2023年も大いに飛躍出来た一年となった(?)のでヨシ!!!

しかし自分は本当にある意味場当たり的に一生懸命生きている運の良いだけの人間なのだなぁと痛感し、持たざる者であることを自覚し、これからもできる範囲で頑張らないといけないなぁ、という気持ち(ガンバレ

blog.tocyuki.com

blog.tocyuki.com

2023年振り返り

まず仕事、登壇&コミュニティ活動という切り口で出来事やイベントを羅列し、それぞれ印象的な出来事を中心に深掘りながら最後に総括という形で全体を振り返っていこうと思います!

仕事

  • CES参加に伴うアメリカ出張(1月)
  • チーム合宿と称してトスラブ箱根和奏林でワーケーション(5月)
  • イオンスマートテクノロジー社へ転職(8月)
  • グループ会社視察に伴う中国出張(9月)
  • テックブログ開設&DevRel立ち上げ(9月)
  • MS Ignite Japan recap参加に伴う大阪出張(12月)
  • アドベントカレンダー実施(12月)

年始早々(1/3〜1/9)CES視察と称した自身初となるアメリカを出張という形で訪れることになった。 これも初となるホノルルで10時間以上あるトランジットを正月からヨットで回遊しながら休憩ポイントでは船上でハンバーガーを作って食べたり海で泳いだりして満喫し、そこからLAへ行きグランドキャニオンのツアーへ参加したり、戻ってからは初カジノで$1,100勝ちからの$500負けでフィニッシュしたり、CESへも参加したり、シルクドソレイユの「O」を観覧したり、フェニックスではWaymo、サンフランシスコではGMクルーズのレベル4自動運転による無人タクシーを体験したりと本当に色々と貴重な体験をすることが出来た。

また2023年はIT健保のレストラン巡りと保養施設でのワーケーションがQOLを高めてくれた。特にIT健保寿司として名高い「一新」や和食レストラン「木都里亭」とチーム合宿と称して行ったトスラブ箱根和奏林はめちゃくちゃ良かった。IT健保加入してるエンジニア諸氏におかれては是非訪れてほしい。

IT健保の素晴らしいレストラン、保養施設について、また活用戦略については前職のマイメンが記事を書いてくれているのでこちらも是非参考にしてほしい。

tech.trustbank.co.jp

2023年最大のイベントは何と言ってもやはり転職だった。

前述の通り、8月にイオンスマートテクノロジー社へCTOのリファラルで転職した。

SREとしてはチームの状態を整えるために詳しくは書けないが色々と精神をすり減らしながら奔走した5ヶ月だった。 中々の苦行だったが種まきを何とか年内に終わらせることが出来たので、2024年はしっかりと成果を上げていきたい。

詳細が気になる方は飲みに誘っていただければベラベラ喋ると思いますのでお誘いお待ちしております🍺

また、中に入ってみて内部への働きかけより外部からのプレゼンスを高めることが色々と近道だと判断し、テックブログやDevRelチームの立ち上げ、アドベントカレンダーの実施などにチャレンジをした結果、これらの活動を通じてエンジニア組織としてのプレゼンスをかなり高めることができた。 特にDevRelチームは増幅拡大の装置としては申し分ない機能を持たせることができたので、今年は採用活動と組織改革を本格的に推進していき強固な地盤固めを行う一年としていきたい。

関連記事は以下

qiita.com

qiita.com

zenn.dev

俺の役割 is 何?という風に感じられる方もいると思うが、前向きな言い方をすると必要なことであれば何でもやれるフェーズであるということです。

登壇・コミュニティ活動

2023年はコミュニティ活動を通じて色々な人と接点を持ったり仲を深める事ができた。 今までコミュニティに関わることで人生が変わった、というような人の話を聞く事がよくあったが、昨年はまさに自分の人生も様々なコミュニティを通じて拡張されていく感覚があった。 今では自分の言葉として「コミュニティに関わることで人生が変わった」と言えるようになったと思う。

ハイライトとしてはCloudflare Meetup Naganoを主催(?)し、長野の技術コミュニティの方々と繋がることが出来たり、NRUG SRE支部メンバーで共著で書籍を出版したり、JAWS-UG コンテナ支部 #24 ecspresso MeetUpでは敬愛するfujiwaraさんやsongmuさんと一緒にお酒を飲んだり、Cloud in the Camp 勝浦で色々な人と交流できたあたりだと思う。

また例年よりも多くの様々なイベント(登壇や主催以外の)へオンライン、オフライン問わず参加したような気がする。

引き続き自分の人生をより豊かにし、学びを得るため、また還元するためにも積極的にコミュニティ活動やイベントへ参加して行こうと思う。

総括

2022年もそうだったが、2023年も本当にイベントや変化の多い一年になった。

なんと言っても転職したことによる変化が一番大きかったが、仕事的にはこの一年で初めてアメリカと中国へ海外出張に行ったり、本を出版したり、ワーケーションと称して伝説のトスラブ箱根和奏林に行ったり(マジ最高だった)、プライベートでは千葉と四国へ家族旅行したり、消防団やサッカーのコーチを始めたり、マイカーを購入したりと人生においても記憶に残るであろう良い経験となるイベントが目白押しでとても良い一年となった。

転職して大変な時期もあったりしたが、あの手この手でなんとか光が見える状況にはなって来たので今年は方針策定して大きな成果を創出していきたい。

ここ数年は仕事のみならず自分の戦略・戦術がハマることが多いのだがディテールが甘かったり大雑把な部分は散見されるのでそういった部分は改善していき、より良い人生を歩めていけるように精進していきたい。

2024年の抱負

個人的な今年の抱負としては以下についてそれぞれ習慣化のための施策を遂行できるように頑張っていきたい。 2024年は継続力をキーワードに習慣化を進めていきたい(自信ないけど)

  • 読書
  • フォーカスすべき技術領域の学習
  • 英語学習
  • 健康

全体の共通施策として「毎週日曜に振り返りと計画を行う」ことを継続していきたい。

読書

主に技術書が対象になると思うが、以下のような施策をしっかりと遂行していきたい。

  • 計画的な積読消化による読書の習慣化
  • アウトプット駆動読書
  • 輪読会の開催

後述するフォーカスすべき技術領域の学習にも関係するが、年間でどれぐらい何を読むかをある程度計画し、読み終わったら書評を書くなどアウトプットとセットで読むようにする。 また、会社のメンバーを巻き込んで輪読会を実施しチーミングも兼ねて相互で学習する仕組みを作り上げる。

読書管理にはブクログを活用するようにする。

booklog.jp

フォーカスすべき技術領域の学習

自分は今までなんでもできるようになりたいという気持ちが強く、学習対象もかなり散漫だったが今後は明確に以下の領域に絞り、Infra/DevOps/SRE/PlatformEngineering領域を強みとしたエンジニアとしてしっかり市場価値も上げていき、会社・事業にもコミットしていきたい。

  • Golang
  • Kubernetes
  • DevOps
  • SRE
  • PlatformEngineering

どのように学習していくかは基本的にはインプットとアウトプットになるわけだが、その主軸は以下だ。

  • 技術書、ハンズオン、実践を通したインプット
  • ブログ、登壇などによるアウトプット

すでに今年もデブサミへの登壇も決まっていたり、TiUGやAEON Tech Talkなどのイベント開催も予定しているのでそれらのイベントやSRE Next、PlatformEngineeringMeetup、CNDTなど大きなカンファレンスでの登壇にもどんどん挑戦していきたい。

event.shoeisha.jp

tiug.connpass.com

そして今年はISUCONにも挑戦したい!!

英語学習

月並みだが以下のアプリでの学習を毎日やる!

  • Duolingo
  • ELSA Speak
  • iKnow

健康

とりあえず意識しながら無理せずという感じで頑張りたい。

  • コーチ業では意識して動く
  • 息子とのサッカー練習では自分の運動も兼ねてやる
  • 毎日ストレッチする
  • 毎日体重を測る

おわりに

とまぁ、こんな感じで雑に振り返ってみたり抱負を述べたりしましたが意味があるかどうかは今後の自分次第だけど良い機会にはなったので引き続き今を一生懸命生きつつ、ほどほどに頑張りたいと思います!

2月には納車、6月には4人目となる子供が産まれる予定(!?)なので今年もイベント目白押しな予感!!

Azure Kubernetes Service関連で役立ちそうなリンク集

色々教えてもらったので備忘録

Microsoftラーニングパス

製品欄のAzure Kubernetes Serviceにチェックをいれた状態のURL

learn.microsoft.com

AKSクラスターのB/Gデプロイ

learn.microsoft.com

API の破壊的変更時に Azure Kubernetes Service (AKS) クラスターのアップグレードを自動的に停止する

非推奨のAPIの使用を確認できるKubernetes API deprecationsが便利そう

learn.microsoft.com

AKSリリーストラッカー

AKS は、すべてのクラスターと顧客に影響を与える一連の修正プログラム、および機能とコンポーネントの更新プログラムを毎週リリースします。 ただし、これらのリリースは、Azure の安全なデプロイ プラクティス (SDP) により、最初の出荷時点からすべてのリージョンに展開されるまで最大 2 週間かかることがあります。 お客様のリージョンが特定の AKS リリースの対象となっている場合にそれを把握することが重要であり、AKS リリース トラッカーは、これらの詳細をバージョンとリージョン別にリアルタイムで提供します。

learn.microsoft.com

AKS CHANGELOG

定期的に読むと良さそう

github.com

AKS Release Note

日本語化されているものがオススメ

zenn.dev

AKS B/GデプロイのTerraformサンプルコード

MS真壁さん作

github.com

Azure Kubernetes Services のトラブルシューティング に関するドキュメント

learn.microsoft.com

KubernetesにArgoCDをセットアップする

blog.tocyuki.com

とりあえずAKSのセットアップができたのでArgoCDをデプロイしてみる

とはいえ基本的には公式に記載されていることをするだけでデプロイできた(k8sすごい)

argo-cd.readthedocs.io

$ 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コマンドで初期パスワードを取得する

$ 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ユーザーを入力してログインできた

ArgoCDログイン後の画面

SRE文脈で読むと良さそうな書籍

SRE文脈な書籍が増えてきたので読んでおくと良さそうなやつを主に以下の分類でピックアップしておく

  • SRE
  • DevOps
  • 運用監視
  • 組織論

SRE

Google SREシリーズ

主著者/寄稿者が(ex-)Google SRE含む

その他

DevOps

運用監視

組織論

おわりに

SRE文脈とは?という感じではあるがSREというロールでいるのであればこのあたりは一通り読んでおきたい(読んでいるとは言っていない)

アーキテクチャ関連書籍はこちらにまとめたのでどぞ blog.tocyuki.com

Macの初期セットアップでやること

ここ2〜3年で検証機なんだかんだ6台ほど新しいMacをセットアップすることがあり、Macの初期セットアップ大体同じことやってるのでなんとなくメモしておく

トラックパッド&キーボード

以下設定する

トラックパッドのスクロール方向変更

自分は現在のデフォルトのスクロール方向とは逆に慣れてしまっているのでまずここを直します

トラックパッドの設定画面から変更する

三本指によるドラッグ有効化

これもめちゃくちゃ便利なので必ず有効化してるんですが微妙に分かりづらい場所に設定が会って毎回一瞬「あれ?どこだっけ?」となるやつ

アクセシビリティ>ポインタコントロール>トラックパッドオプションから変更

ドラッグにトラックパッドを使用にチェック、ドラッグ方法に3本指のドラッグを選択

caps lock^(control)へ変更

使うことない&HHKBのキー配置に合わせて変更

キーボード>キーボードショートカットから設定

修飾キーから変更

感度系

キーボード、スクロールなどなどの感度系を最速にしておく

リピート速度&入力認識の時間を最速に

軌跡の速さを最速に

dotfilesリポジトリ

dotfilesリポジトリを運用しているのでこいつをgit cloneしてタスクランナーであるMakefileで諸々実行して必要なアプリや設定をする

github.com

iTerm2

ログインシェル変更&tmux自動起動

自分はシェルにtmux&fishを使っている使ってるので設定していく

GeneralのCommandで設定

おわりに

dotfiles&ansibleによる構成管理をしているため結構楽にセットアップできてるので良きだなぁと改めて思うなどした

Azure Kubernetes Serviceへ手元のMacからkubectl実行する

というわけで(?)Azureなんもわからんマンなのでazure-clikubectlで手元から構築したKubernetes Clusterへの接続方法をメモしておきます。

Azure CLIでAzureへログイン

$ az login

サブスクリプションを設定

サブスクリプション一覧を表示して対象となるサブスクリプション名 or サブスクリプションIDを取得

$ az account list -o table

取得したサブスクリプション名 or サブスクリプションIDを指定してサブスクリプションを設定

$ az account set --subscription <サブスクリプション名 or サブスクリプションID>

AKS認証設定

AKSクラスタ名とリソースグループ名を取得

$ az aks list --output table

取得したAKSクラスタ名とリソースグループ名を使って認証する

$ az aks get-credentials --resource-group <resource_group_name>  --name <cluster_name>

kubectl実行

あとは各種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

よし、起動した

アーキテクチャ関連で読みたい書籍

色々なアーキテクチャを勉強するにあたり、とりあえずこのあたりは読んでおくと良さそうという書籍をピックアップ(全部読んだとは言っていない)

ソフトウェアアーキテクチャ関連

DDD/クリーンアーキテクチャ関連

マイクロサービス関連

JetBrains系IDEのIdeaVimプラグインでNERDTreeが使えるだと!?

というわけで普段はIntellijIDEAをメインに使っているんですが、元々Vimをメインで使っていたのでもちろんIdeaVimプラグインは使っていました。

ファイラーの扱いだけちょっとなーと思っていたんですが、使っているキーボードのカスタムキーバインドでなんとかやっていたところNERDTreeのキーバインド使えるんかいとなったので導入したのでそのメモ書きとして残しておきます。

使い方

基本的には以下に記載があるので要参照。

github.com

サポートしているコマンド

コマンド 説明
: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ライフを送れそう🫶

EBSボリューム拡張

N億年ぶりにディスク拡張したので備忘録

環境

  • Ubuntu 18.04.2 LTS x86_64
  • EC2

手順

概要

  • EBSボリューム拡張
  • OSにボリュームを認識させる
  • ファイルシステムを拡張する

EBSボリューム拡張

AWSのマネコンから実施

EC2インスタンスを選択してストレージタブからEBSボリュームIDを選択

EBSボリュームを選択してアクションからサイズを変更する

OSにボリュームを認識させる

現状を確認

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

参考

docs.aws.amazon.com

tech.innovator.jp.net

ALB+EC2+RDS+EFS構成でWordpress環境を作ったらCSSが崩れてハマった

というわけで、何度現場を移ってもWordpressから逃げられないんですよこれが。

久しぶりに1から構築するということでEFSの速度改善もしたし、使ってみるかぁという感じでやってみました。

aws.amazon.com

しかし構築したもののCSSが適用されず微妙にハマり以下のQiita記事を見て膝からがっくり落ちましたよ。。。

qiita.com

とりあえずfastcgi_paramHTTPS onを渡して対応しておしまい。 あとはRedisとS3を準備しておけばOKかな〜。

TerraformでDynamoDBのロックがおかしくなってplanできなくなった時の対応

その時は急にやってきた

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.
╵

ロックの強制解除をしてみる

はいはい、強制解除強制解除ぐらいのノリで、ツイートしたりしちゃうぐらい呑気な感じでした。

$ 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
│ 
│ 
│ 
╵

DynamoDBテーブルの確認

上記のエラーで出ている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
}

update-itemでDigestを更新

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
}

再度、コマンド実行してみたところ、planapplyも問題なく実行できるようになりました!

参考

pygillier.me

MySQL5.7でibtmp1が枯渇した際の対応

ibtmp1が枯渇してCPUのアラートが上がってその対応をしたのでメモ

ディスク状況の確認

/mnt/extdiskが100%になっちゃってるよ

[root@db:~]# df -h
Filesystem                      Size  Used Avail Use% Mounted on
devtmpfs                        985M     0  985M   0% /dev
tmpfs                          1000M     0 1000M   0% /dev/shm
tmpfs                          1000M  105M  895M  11% /run
tmpfs                          1000M     0 1000M   0% /sys/fs/cgroup
/dev/vda3                        16G   12G  3.7G  76% /
/dev/mapper/vg_extdisk-lv_data   99G   94G     0 100% /mnt/extdisk
tmpfs                           200M     0  200M   0% /run/user/0
tmpfs                           200M     0  200M   0% /run/user/1000

innodb_temp_data_file_pathの設定を確認

デフォルトのままっぽい

mysql> SELECT @@innodb_temp_data_file_path;
+------------------------------+
| @@innodb_temp_data_file_path |
+------------------------------+
| ibtmp1:12M:autoextend        |
+------------------------------+
1 row in set (0.00 sec)

innodb_temp_data_file_pathの設定変更を実施

とりあえず10Gを上限とするように/etc/my.cnfに記述を追記

[mysqld]
innodb_temp_data_file_path=ibtmp1:12M:autoextend:max:10G

設定が反映されたか確認

サーバー再起動しないと設定反映&ibtmp1の領域が開放されないので再起動を実施

/mnt/extdiskが5%にちゃんと減っちゃってるよ!

[root@db:~]# df -h
Filesystem                      Size  Used Avail Use% Mounted on
devtmpfs                        985M     0  985M   0% /dev
tmpfs                          1000M     0 1000M   0% /dev/shm
tmpfs                          1000M  8.7M  991M   1% /run
tmpfs                          1000M     0 1000M   0% /sys/fs/cgroup
/dev/vda3                        16G   12G  3.7G  76% /
/dev/mapper/vg_extdisk-lv_data   99G  4.3G   90G   5% /mnt/extdisk
tmpfs                           200M     0  200M   0% /run/user/0
tmpfs                           200M     0  200M   0% /run/user/1000

ibtmp1の設定も無事反映されてるよ!

mysql> SELECT @@innodb_temp_data_file_path;
+-------------------------------+
| @@innodb_temp_data_file_path  |
+-------------------------------+
| ibtmp1:12M:autoextend:max:10G |
+-------------------------------+

参考情報

docs.oracle.com

AWS DMSでDB移行をした際に移行されない属性を移行するためのSQL文

今、お仕事でとあるIaaSからAWSへのインフラ移行をしていて、DMS(Database Migration Service)を使っててめちゃ便利で最高なんですけど、これインデックスやらプライマリーキーに設定されているAUTO_INCREMENT属性やらもろもろ移行してくれないものがあります。

docs.aws.amazon.com

ただし、 AWS DMS はターゲットデータベース内にセカンダリインデックス、外部キー、ユーザーアカウントなどを自動的に作成しません。

docs.aws.amazon.com

列の AUTO_INCREMENT 属性は、ターゲットデータベース列に移行されません。

というわけでもろもろの属性を移行するためのSQLを書いたので覚書のため記載しておきます。
{SCHEMA_NAME}は対象のDBスキーマに読み替えてください。

Index移行用SQL

SELECT
  CONCAT(
    "ALTER TABLE ",
        t1.table_name,
        " ADD INDEX ",
    t1.index_name, 
    "(",
    (
      SELECT
        GROUP_CONCAT(DISTINCT t2.column_name SEPARATOR ', ')
      FROM
        information_schema.statistics AS t2
      WHERE
        t1.index_name = t2.index_name AND t1.table_name = t2.table_name
      ORDER BY
        t2.table_name,
        t2.index_name,
        t2.seq_in_index
    ),
    ");"
  ) AS alter_table_add_index_query
FROM
  information_schema.statistics AS t1
WHERE
  table_schema = "{SCHEMA_NAME}" AND index_name != "PRIMARY"
GROUP BY
  t1.table_name,
  t1.index_name
;

プライマリーキーのAUTO_INCREMENT属性移行用SQL

SELECT
 CONCAT(
   "ALTER TABLE ",
   TABLE_NAME,
   " CHANGE ",
   COLUMN_NAME,
   " ",
   COLUMN_NAME,
   " ",
   COLUMN_TYPE,
   " AUTO_INCREMENT;"
 ) as alter_auto_increment
FROM
 information_schema.columns
WHERE
 table_schema = "{SCHEMA_NAME}"
and is_nullable = "NO"
and column_key = "PRI"
and extra = "auto_increment"
;

おわりに

あとはそれぞれ生成したALTER文を移行先のDBで流せばOKです! 動作責任は負いかねますが、どなたかの助けになれば嬉しいです!

おまけ

外部キーを貼っているテーブルに関する調査もしたのでその際に確認したコマンドも記載しておきます。

外部キーを貼っているテーブルの調査

select * from information_schema.table_constraints where table_schema = "{SCHEMA_NAME}" and constraint_type = "FOREIGN KEY";

特定のテーブルへの外部キーを貼っているテーブルの調査

select distinct(referenced_table_name) from information_schema.key_column_usage where constraint_schema = "{SCHEMA_NAME}";