Kubernetesでアプリの安定稼働と高頻度のアップデートを両立するためのプラクティス / Best Practices for Applications on Kubernetes�to Achieve Both Frequent Updates and Stability
はじめにクレディセゾンに来てちょうど5年が経ったので、これまでの取り組みをまとめてみようかと思う。書き進めていくうちにとても長くなってしまったので、1年につき3トピックに絞ってあとはカットした。それでも5年分なこともありかなり長くなったので、目次から各トピックに飛んでもらえればと思う。社内の関係者も読むかもしれず、「自分のやったことが載ってない!」と思うこともあるかもしれないが、内製開発案件だけでも53案件あり全部載せるととんでもない量になるので許してほしい。それから、振り返ってまとめると退職すると勘違いされるかもしれないけれど、退職するわけではありません! 2019年:ゼロからのスタート1-1. 内製開発エンジニア募集を始める「日本のそれなりの規模の事業会社の中に、内製開発チームを立ち上げることはできるのだろうか?」 2019年3月、クレディセゾンに来たばかりの私にとってはこの質問への答
はじめに データ分析基盤の資料を力尽きるまで追記していきます。 構成図にあるアイコンや記事の内容から技術要素を調べて記載していますが、不明分は未記載にしています。修正のコメント頂ければ助かります。 あと、この記事追加してっていう要望も歓迎いたします。 テンプレート 記事公開日 : 会社名(サービス名) データソース : データ処理 : アウトプット : 画像 URL 2025年 2024/03/14 : 株式会社エス・エム・エス(カイポケ) データソース : Amazon Aurora データ処理 : Datastream、BigQuery、dbt アウトプット : Looker Studio 2024/03/12 : 株式会社マイナビ データソース : SQL Server、Amazon S3 データ処理 : Embulk、Amazon MWAA、Apache Airflow、Snowf
EnterpriseProductEnterprise managed users are now generally available for GitHub Enterprise CloudManage your company in the cloud with more control and governance using enterprise managed users. The future of software development is in the cloud. At GitHub, we are focusing on making the transition to cloud an easy path for companies of all sizes. Today, we’re pleased to announce that enterprise ma
この記事は enechain Advent Calendar 2023 の25日目の記事です。 最終日は CTO の須藤( @sutochin26 )がお送りします。 メリークリスマスですね。弊社としては初の Advent Calendar でしたが、無事最終日を迎えることが出来ました。 今年から Tech Blog を初めて、「年内に30本書くぞ」と目標を立てましたが、この記事で40本目になるみたいです。エンジニアに限らず、デザイナー、PdMも参加し、Tech本部総力戦で目標達成という感じでめでたい限りです。 技術の話は他の皆が沢山してくれたので、私からはカルチャーに関する話をしたいと思います。 CTO就任後、カルチャーとどう向き合い、どんな事をしてきたかについてお話します。 カルチャーに対する想い カルチャー醸成に向けた動き やったこと やっていないこと 想いはそんなに簡単に伝わらない
OLTA (オルタ) の橋山です。 最近は、吉本の芸人をやっている弟とMagic The Gathering ARENAをやっています。Magic The Gatheringを語り出すとそれだけで記事が3本ぐらい書けてしまうのですが、それは別の機会に回したいと思います。 さて、去年より大事な仕事の1つとして取り組んでいた開発組織の目指す姿をOLTA Tech Visionとして本日公開します。 OLTA Tech Visionができるまでは本当に苦労の連続でしたが、作るまでの過程が何かの参考になれば、と思い記録に残すことにしました。 なぜ Tech Vision を作る必要があったのか?約1年半前まで遡りますが、当時、OLTAの開発組織は厳しい状態に瀕していました。エンジニア1人1人の能力は非常に高く、優秀な業務委託や副業メンバーにも手伝ってもらっていましたが、チームとしての一体感に欠け、
この記事は、はてなエンジニア Advent Calendar 2023の2024年1月17日の記事です。 はてなエンジニア Advent Calendar 2023 - Hatena Developer Blog id:hagihala です。先日、はてなブログの DB を RDS for MySQL 5.7 から 8.0 へアップグレードしたので、工夫した点などを共有します。 Aurora MySQL 3.x にしなかった理由 MySQL 5.7 -> 8.0 で対応した変更点 character set や collation のデフォルトが変更される explicit_defaults_for_timestamp がデフォルトで有効になる SQL mode の変更 デフォルトの認証プラグインが caching_sha2_password になり、 mysql_native_passw
はじめに約1年ぶりのエントリーになります。今回はマネージャーの評価基準というタイトルで書きたいと思います。 マネージャーを評価する基準というのはありそうでないなと、この1年色々な経営者・マネージャーの方と話す中で感じていました。 その時残すべき成果が出ていればマネージャーとしてOKとしている会社もあれば、「マネージャーとしての行動リスト」のようなものが5個〜多くて30個程度であり、その行動リストを評価とまではいかなくとも、チェックリストのように使っている会社もあります。 しかし、前者の場合は「成果が出ていれば色々な犠牲が出てもよし」となりますし、後者の場合は「行動リストのうち今必要が無いことも行動せよ」となるので、両方ともマネージャーを評価する基準としては何か違うなと違和感を覚えてました。 しかし、何を以て良いマネージャーなのか、それを判断する基準がなければ、マネージャーに何を求めて良いか
前回の記事ではチーム中心の組織づくりの設計原則について書いた。今回は、それらの原則に基づくチームをソフトウェアプロダクト組織内にどう配備し、どのような機能を持たせるかについて考える。これは言わば、チームの責務を定義することに他ならない。本記事ではこれを、7つのガイドラインとして書き出してみることにした。 前回の記事:『チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog』 mtx2s.hatenablog.com 1. ストリームアラインド 2. オーナーシップ制 3. バリエーション分割 4. 技術横断型 5. DevOps 6. 機能横断型 7. マルチスキル 組織設計とはアーキテクティングである 1. ストリームアラインド ソフトウェアプロダクト組織の開発フローは、ユーザーや市場の観察をもとにアイデアを生み出すことから始まる。そのアイデアを仮説として、それを
「財務会計システムの上で管理会計もやろうとするのは悪手です」 顧客と話していて、こう忠告することがある。筆者は現在、公認会計士として、決算の早期化やDX(デジタルトランスフォーメーション)の推進について主に中堅・中小企業へ助言する仕事をしている。 管理会計というと堅い感じがするが、要するに、企業の経営者の意思決定に役立つ情報を提供することだ。つまり、将来の経営改善が狙いであり、ビジネスを大きく変えるDXを進めるためにも管理会計は必須になる。 「あれはどうなっているか、それが分かれば手が打てる」。このように経営者は様々な指標を気にしており、管理会計へのニーズは大きい。 業績を報告するためにほとんどの企業は財務会計システムを使っているので、これを利用して管理会計ができないか、という相談を受けることがしばしばある。 だが、管理会計と財務会計はどちらもお金を扱うものの、狙いも方向も大きく異なる。管
はじめに 私は、さくらインターネットというクラウドサーバの会社の社長をしていて、よく経営者の方からのメンタリングのリクエストをいただくことがあります。 その中で多くの割合を占めるのが、ITエンジニア(以降、エンジニア)のマネジメントと、エンジニア組織の構築をどのようにすればいいのかというテーマです。 確かに、どんなビジネスをするにしても、単にSaaSやノーコードツールを活用するだけでは足りなくて、自分たちでシステム開発しないといけないケースが増えてきているのは、間違いないなと思います。 外注をしてシステム構築をするケースももちろん多いですが、基幹システムのような使いにくくても自社の社員が我慢すればいいものと違って、自社のお客様向けのシステムだと使いやすくないとお客様が離脱してしまいますし、常にアップデートをし続けて、最良のUI/UXを作ることが業績に直結します。 要は、今のデジタルシステム
2023/12/15開催のEMゆるミートアップで話した内容です。 linkや当日お話した部分、誤解を生みそうな部分に関していくつか補足を書いておきます。 - p5~p11 補足: EMは会社や事業、チームの状況によって、求められることが違うので、弊社のプロダクトや自分の立場についてお話しています。それを踏まえて資料を御覧ください。 - p13 link: HIGH OUTPUT MANAGEMENT - p17 link: LayerX羅針盤 - p19 link: 相互理解の重要性と、促進するためのワークショップのご紹介 #LayerXテックアドカレ -p23 補足: 委譲度は、図解真ん中の「同意する」がちょうど合議で決めるラインで、それより左はMgrが意思決定している状態で、右がメンバーに委譲して意思決定している状態です。徐々に右に進み、委譲度が大きくなるように意識しています。メンバー
[2024年1月10日、19日追記] GmailとYahoo!側のアップデートに合わせていくつか細かい説明を追加しています(大筋は変わっていません)。変更点だけ知りたい方は「追記」でページ内検索してください。 2023年10月3日、Googleはスパム対策強化のため、Gmailへ送るメールが満たすべき条件を2024年2月から厳しくすると発表しました。また米国Yahoo!も、2024年2月 第一四半期[1] から同様の対策を行うと発表しています。端的に言えば、この条件を満たさないと宛先にメールが届かなくなるという影響の大きな変更です。 この記事では、Gmailや米国Yahoo!の規制強化への対応方法を解説します。ただし米国Yahoo!にメールを送る人は多くないと思うので、フォーカスはGmail寄りです。また、メール配信サービス(海外だとSendGridやAmazon SES、国産だとblas
はじめに こんにちは。メルペイVPoEの@keigowです。 この記事は、Merpay Advent Calendar 2023 の2日目の記事です。 今年の3月まではソウゾウでHead of Engineeringとして働いていましたが、4月にメルペイに2年ぶりに戻ってきました。本日はメルペイのProduct組織の改善とProgram組織への移行の取り組みについてご紹介します。 以前のProject Matrix型組織 2022年9月までは、Microservicesの単位をベースとして構成されたFunctionチーム(Growth、Platform、与信領域など)から、3ヶ月ごとに決めているProject(新機能開発、他社連携など)に各メンバーをアサインしていくという形でProduct開発を推進していました。 会社のOKRとして合意した目標に沿って、Productチーム内でProjec
2023/12/13 aria-disabledの付け方を改良 2023/12/11 タイポ修正 2023/12/08 next/linkのhrefにundefinedを渡すとエラーがでるため、disabledにする方法を修正 <Button asChild ref={}>とrefを指定できてしまっていたのを修正 セミコロンをつけないように 2023/12/07 タイポ修正(priamry -> primary) import { cloneElement, forwardRef, isValidElement } from "react" import styles from "./style.module.css" import clsx from "clsx" export type ButtonProps = { variant?: "primary" | "secondary"
Nissyさんに誘われて、Cyber-sec+で記事を書かせて頂くことになりましたkobayayoと申します。 普通の事業会社で情シス業務をやりながら、セキュリティ業務を担当しています。 専業でセキュリティやっている訳じゃないので、全然詳しくありませんよ。 どこまで続けられるのか心配ではありますが、頑張ってやってみますよ。 サイバーセキュリティを考えるうえで、情報の収集はその第一歩として必要になるものです。「彼を知り己を知れば百戦殆からず」ってやつですね。「孫子・謀攻編」に見える格言です。 そこで、情報セキュリティ担当者が攻撃者に先行的に対処していけるようにするための、情報収集、すなわちOSINTの活用について書いてみたいと思います。 OSINTの定義 「OSINT」とは、Open Source Intelligenceの略称で、公開された情報を収集・分析することで、情報収集や情報分析を行
※本記事は2019年2月26日のCTOイベントをもとにした内容です。 【写真:左から、Sansan CTO 藤倉さん、LIFULL CTO 長沢さん、イベント主催者flexy岡田、3社CTO 白井さん、メルペイ VPoE 木村さん】 2019年2月26日、大人気イベントとなり席枠を拡大して開催されたCTO meetup。「エンジニア組織のあり方~気になる各社の仕組みを公開~」をテーマに、各社のCTO、VPoEがディスカッションを行いました。 エンジニア組織をまとめあげる立場の方たちがどのように意思決定を行うのか、どのような意図をもってさまざまな仕組みを導入しているのか、CTOのミッションとは一体どういうものなのかを紐解く、充実の内容となりました。豪華なご登壇者をお迎えし、成功事例だけではなく、困難な状況や失敗事例などに対する生の声を織り交ぜながらのディスカッションをレポートします。 CTO
Adways Advent Calendar 2020 4 日目の記事です。 どうも、大曲です。 今日はMGRとして事業貢献を目指して色々と模索したものを簡単に紹介できればいいなと思います。 社内で改善したログをつなぎ合わせたものになりますので、読みにくい部分があると思います。 ご了承ください。 書くこと 組織体制とOKRの変化 OKRの目標内容(細かい説明はなし) 書かないこと OKR運用の話(フィードバックや振り返り) 事前説明 言葉の定義 ユニット・・・1開発チームを指す Div・・・複数の開発チームが所属する組織を指す UM・・・ユニットのエンジニアリングマネジャー(スクラムマスター、1on1) チーフ・・・ユニットのテックリード(技術選定、サービス品質管理..etc) テックリードの定義と運用に関して Div MGR・・・Divのマネージャー リードチーム・・・組織体制(ユニット
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く