本番環境でやらかしちゃった人のアドベントカレンダーです。 例) 本番DB吹き飛ばした 本番サーバをデストロイした ネットワーク設定をミスって本番サーバにアクセス出来なくなり、サーバが世界から孤立した などなど... 以下の2点については必須項目なので、記述お願いします。 惨劇はなぜおこってしまったのか 二度と惨劇を起こさないためにどうしたのか もう二度とあの惨劇を繰り返さないために、みなで知見を共有しましょう。
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
オラクルは、同社が提供している企業向けのJavaディストリビューションであるOracle JDKのライセンスを変更し、無料で本番環境などでの利用を可能にしました。 同社が9月14日付で公開したブログ「Introducing the Free Java License 」で、次のように説明しています(関連するプレスリリース「Oracle Releases Java 17」)。 Oracle JDKを無料で提供し、四半期ごとのセキュリティアップデートも提供する。 新ライセンス「Oracle No-Fee Terms and Conditions (NFTC)」は、商用利用や本番環境での利用を含むすべてのユーザーに対して無料での利用を許可する。 Oracle JDK 17から、この無料のリリースとアップデートの提供を開始する。これは次の長期サポート(LTS:Long Term Support)が
(この記事は 地平線に行く とのマルチポストです) 本番環境でやらかしちゃった人 Advent Calendarで、このパターンのやらかしはなかったのでキーボードを叩くことにしました。 番外編のつもりでお楽しみください。 この記事が、新たな障害発生を防ぐことにつながれば幸いです。 何をやったのか ある日、ちょっとした調査のために本番データベースのデータを確認することになりました。 (個人情報が格納されているようなシステムではなかったので、必要であれば本番データベースへのアクセスが許されていました) もしメンテナンスがあればそのタイミングでやればよかったのですが、直近では特に予定はないとのことでした。そのため、システムが動いている状態のまま作業をすることにしました。 ごく単純な SELECT を実行するだけのつもりだったので、システムに影響がないと判断したためです。 その際、万が一コピペをミ
はじめに 私は個人開発で一山当てたいと常々思っていて、そのためにいくつかヒットしそうなサービスのアイデアがあります。エンジニアであればアイデアを具現化することに躊躇してはいけないと思うわけですが、一度リリースしてしまうとランニングコストが発生するわけで、仮に全く人気がでなかったとしたらランニングコスト分の赤字を垂れ流すことになります。 一方、個人開発者というのはおそらく誰しも夢見がちなので、リリース後バズったりしてユーザーが大量に押し寄せてきてしまってサーバーダウンする可能性も考えてしまいます。 その結果、「全く誰も来なくてランニングコストが赤字になったらどうしよう」という不安と「めちゃくちゃバズってしまってサーバーダウンしてチャンスを逃したらどうしよう」という不安が、心の中でせめぎ合うことになります。 そこで、今回はその2つの不安を一気に解消する「使われなければランニングコストが限りなく
この記事は本番環境でやらかしちゃった人 Advent Calendar 2019 17日目の記事です。 はじめまして、ダーシノ(@bc_rikko)です。 突然ですが、懺悔します。 私は転職して10ヶ月で2回も本番環境をぶっ飛ばしました。お客様をはじめ、関係各位には多大なるご迷惑をおかけしたことを、ここでお詫び申し上げます。 1回目は2015年11月27日、入社27日目のこと。 gitの設定ミスにより壊れたブランチをmasterにforce pushしてしまい、CIが流れて本番環境が壊れた。原因はpush.defaultなのだが、詳しくはすでに記事を書いているのでそちらを読んでほしい。 2回目は翌年9月1日、入社してちょうど10ヶ月たった日のことだ。 またしても本番環境をぶっ飛ばした。しかも、前回より盛大に……。 タイトルにもあるようにrsyncコマンドが原因だ。 当記事では、この「rsy
本文の内容は、2022年8月29日にAlejandro Villanuevaが投稿したブログ(https://sysdig.com/blog/26-aws-security-best-practices/)を元に日本語に翻訳・再構成した内容となっております。 Well-architected フレームワークの最も重要な柱の1つは、セキュリティです。したがって、AWSセキュリティベストプラクティスに従って、不測なセキュリティの事態を防止することが重要です。 さて、あなたは問題を解決するために、ソリューションを構築してホストする目的でAWSに着目しました。アカウントを作成し、コーヒーを淹れてワークステーションに座り、設計、コーディング、ビルド、デプロイをする準備はすべて整いました。しかし、そうではありません。 ソリューションの運用性、安全性、信頼性、パフォーマンス、費用対効果を高めるには、多く
インスタンスのひとつ「S512」には、サービスの中でも特に重要な部内SNS「traQ」と部員管理システム「traPortal」、認証基盤「pipeline」がデプロイされています。 ArchLinuxくん... SysAd班では、これらVPSのOSにArchLinuxを採用しており、当時のカーネルバージョンは5.12.3-arch1-1でした(たぶん)。 ArchLinuxはUbuntuやCentOSと異なり、SimplicityやModernityの思想からパッケージのRolling releaseを採用しています。 Simplicity 不必要な追加や修正がないこと オリジナルの開発者(アップストリーム)によってリリースされたソフトウェアを、ディストリビューション(ダウンストリーム)特有の変更を最小限に抑えた状態で出荷する ディストリビューションのQAは最小限で、アップストリームによる
タイトル通りですが、1年目エンジニアのインフラのイの字も知らなかった私が1ヶ月半かけてKubernetesで環境構築するまでの失敗の軌跡です(そして環境構築できたのが奇跡)。 理想的にはこれを読めばインフラ初心者でもKubernetes(以下k8s)で環境構築できるところまで説明することですが、そういうわけでなく、環境構築の解説というより自分の失敗やつまづきポイント、役に立ったことをただただ書き連ねていきます。ただ他の初心者の方も同じようなところでつまづくこともあると思うので少しでもお役に立てたら嬉しいです。 バックエンド側で使った技術は以下になっています。 言語:Ruby(RoR) API:GraphQL インフラ:Azure その他:Docker、k8s 実際の実装でハマったところは各章の最後に教訓として簡単にまとめてはいますが、大事なことは先に結論として述べておきます。 Docker
EC2 (Amazon Linux) Apache php7.1 私がやってしまったこと この事件が起きたのは2020年6月。既に稼働しているWebサービスでとあるデータ取得の処理が止まってしまっているので調査してほしいと頼まれました。また、サービスに影響が出るものだからなるべく早めに対処してほしいと言われました。 マネージャー 「今日の夕方までにはお願いね。もし難しそうだったら午後イチで一旦MTGしよう。14時までに連絡をください。」 わたし 「任せてください!」 ・・・・ とは言ったものの、本番サーバーで起きている障害の調査は今までやったことがありませんでした(もちろん本番サーバーにログインしたこともない)し、進め方も全く思いつきませんでした。しかも、対応するサービスの開発には携わったことがなく、sshログインの設定から行う次第でした。 まあ、今まで頼まれたタスクを期限内に終えられなか
CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン
https://x.com/HighWiz/status/1817197569099051158 マリーアントワネット「検証機がないなら,本番環境を使えばいいじゃない。」 これに対し,日本のITエンジニアたちは激おこである。 そして大半が本番環境でテストをするのはけからんという話に終始している。これが日本の姿である。 まるでオライリーの「オブザーバビリティエンジニアリング」で書かれていた本番環境をガラスの城として扱っているパターンそのものって感じがある。 https://netflixtechblog.com/tagged/chaos-engineering 一方,Netflixのようなグローバル大企業はすべからく本番環境でテストを行っている。 彼らは惑星規模の計算資源とその上で稼働する大規模なマイクロサービスを運用しているので,事実上,本番環境と同等の検証環境を作ることができない。 さら
こんにちは。SREチームの吉澤です。 アンドパッドでは最近、AWSのS3バケット上のファイルをスキャンするために、アンチウイルスソフト Antivirus for Amazon S3 を本番環境に導入しました。その結果、私たちの要件はほぼ全て満たされたうえに、従来比で大幅なコスト削減を実現できました。 Antivirus for Amazon S3について日本語で書かれた記事はまだ少ないですが、S3に対するウイルススキャンが求められるケースでは、導入を検討する価値があるソフトです。 そこで、今回はこのAntivirus for Amazon S3の概要、私たちが本番環境に導入してみてわかったメリットやデメリット、そしてこのソフトが適した状況をご紹介します。 背景 S3に対するウイルススキャンが必要な理由 Antivirus for Amazon S3の導入前に利用していたソフト Antiv
Microsoft 365の大規模障害、原因は未検証アップデートがデプロイシステムのバグにより通常のプロセスをバイパスして本番環境へ直接デプロイされたこと マイクロソフトのサービス「Microsoft 365」で、日本時間の9月29日午前6時半頃から約3時間ほど障害が発生し、全世界でOneDriveやOutlook、Teamsなどのサービスに接続しにくくなっていました。 We're investigating an issue affecting access to multiple Microsoft 365 services. We're working to identify the full impact and will provide more information shortly. — Microsoft 365 Status (@MSFT365Status) Septem
個人開発者はRed Hat Enterprise Linuxを無料で最大16システムまで利用可能に、本番環境もOK。Red Hatが開発者向けプログラムの拡大を発表 Red Hatは、個人開発者向けに提供している「Red Hat Developerプログラム」を拡大し、個人開発者には無料で最大で16システムまで本番環境でも利用可能にすることを発表しました。 これは先月発表された、CentOS 8のサポートを2021年末までとし、今後はCentOS Streamの開発に注力することへの影響を考慮したもの。 Last month, we announced updates to the CentOS community and CentOS Stream. Today we’re sharing details about some of the new no- and low-cost pr
SREチームの橋本です。今回はステージング環境の運用でありがちな本番との差分に対処する試みを紹介します。 背景 ステージング環境について、例えばIT用語辞典では ステージング環境とは、情報システムやソフトウェアの開発の最終段階で検証用に用意される、実際の運用環境と変わらない環境のこと。 と説明しています。検証用ですから、インフラ面で言っても本番環境となるべく一致した構成であってほしいということになります。 しかし実際にはさまざまな経緯(ステージング環境を後から立てたり!)から、たとえTerraform管理していたとしても差異が発生してしまうことがあります。 こうしたとき、その差異を検出する一つの方法としてはTerraformの.tfファイルを比較することですが、これにもいろいろな書き方がありえます。 例えばaws_db_proxy_endpointはterraform-provider-a
はじめに この記事について こんにちは、 @zomysan(Twitter) です。この記事では、Next.js で開発をしているWebアプリケーションのフロントエンドを対象に、開発途中のページをどう扱うかということについて書きます。 新しい機能やリニューアルのための開発を始めてあたらしいページを追加したものの、まだ途中なのでユーザーに見せられる状態ではない、ということはよくあると思います。ユーザーには見せたくないけど、開発環境やステージング環境では確認したい。でも本番環境には出したくない。そういうときどうしたら良いのでしょうか? この記事の対象 この記事は以下のような人を対象としています。 Next.js で Web アプリケーションを実装している 開発中のページを本番環境に露出したくない まとめ 今回、私は以下のように実現してみました。 開発中のページについて、拡張子を .page.d
皆さんは予期せぬ事態が起きた時どうしますか? 特に、予期せずやらかしてしまった時は冷静さを欠いてしまい、あらぬ方向へ進んでしまう人は多いと思います。 大事なのは事が起きしまった後に如何に対処できる事後処理能力と振り返り、そもそも事件が起こってしまわないようにするための事前対策です。 今回は私が参加していたとあるプロジェクトにて、私の事前調査が不十分だったせいで起きてしまった話をご紹介いたします。今回の事故が少しでも皆さんの役に立てればと思います。 開発背景 私が関わっているとあるプロジェクトの一部はFirebaseにて運用されています。特にフロントエンドはFirebase Hostingで配信されており、デプロイはGitHub上で特定のリリースタグを切ると自動でリリースされます。 Firebase Hostingはとても簡単にデプロイできます。どのくらい簡単かと言うと、firebase d
DMMグループ Advent Calendar 2019 - Qiita の25日目です TL;DR AWSで3層アーキテクチャのサービスを構築するテンプレート(ここではスターターキットと呼びます)を公開しました。 利用するコンポーネントとしては主にAWSのALB・ECS/Fargate・Aurora、Dockerとローカル環境用にdocker-compose、IaCにTerraformを利用しています。 導入や既存メンバーのためのスターターキットで使用するコンポーネントの入門用ドキュメントを備えています。 概要 y-ohgi.github.io/starterkit にgitbookとしてドキュメントを公開しているのでそちらを閲覧してください。 サンプルとしてGolang・ECS/Fargate・Aurora(MySQL)で構築をしています。 また、RailsやNextなど、コンテナベー
皆さんこんにちは。虎の穴ラボの辻村です。 この記事は「虎の穴ラボ 夏のアドベントカレンダー」17日目の記事です。 目次 目次 対象とする読者 前提 開発・実行環境 ホスト環境 Docker環境 既存環境調査 アプリケーションサーバー OSバージョンに基づく対応イメージ特定 Amazon Linux 2の場合 CentOSの場合 ライブラリ確認 まずはコンテナ作成 ライブラリバージョン突合 依存ライブラリリストの見方 Rubyのバージョン突合 Dockerfile記述例 Bundlerのバージョン突合 Dockerfile記述例 サーバーのタイムゾーン突合 Dockerfile記述例 サーバーの言語設定突合 Dockerfile記述例 所属グループ突合 Dockerfile記載例 その他使用ミドルウェア、ライブラリ突合 DBサーバー バージョンを確認 キャラクターセット、照合順序設定、タイム
IDC JapanはDockerなどのコンテナ仮想化技術とコンテナオーケストレーションツールのKubernetesの導入状況に関する調査結果を発表しました。調査を実施したのは2020年2月。国内の企業および組織458社に対するアンケート調査です。 調査結果によると、コンテナを本番環境で使用している企業は14.2%となり、2019年調査から5.0ポイント上昇しました。また、コンテナを知らないという回答が大きく減少し、コンテナが市場全体で認知されたとも言えます。 最も使われてるオーケストレーションツールはコミュニティ版Kubernetes コンテナを本番環境で使用している企業と、導入構築/テスト/検証段階にある企業を対象に、コンテナオーケストレーションツールについて調査した結果(複数回答)、54.7%の企業がKubernetes(コミュニティ版)を使用しているとの回答がありました。こちらも、2
動機 開発環境・本番環境でdockerを使ってみよう!と思って試したところ何点か詰まったので備忘録としてNext.jsをdockerで環境構築する方法を記しておきます。 開発環境 公式のテンプレートをもとに作っていきます。 FROM node:18-alpine WORKDIR /app COPY package.json yarn.lock* ./ RUN if [ -f yarn.lock ]; then yarn --frozen-lockfile; \ else echo "Warning: Lockfile not found. It is recommended to commit lockfiles to version control." && yarn install; \ fi COPY src ./src COPY public ./public COPY next.
Javaのネイティブバイナリ生成可能なGraalVMの全機能が無料に、最適化コンパイラやG1ガベージコレクションを含む。本番環境でも利用可能 オラクルは、同社がJavaディストリビューションとして提供しているGraalVMの新ライセンス「GraalVM Free Terms and Conditions」(GFTC)を発表し、あわせてこれまで有償版のGraalVMに含まれていた全ての機能を含む新ディストリビューション「Oracle GraalVM」の提供を開始しました。 GFTCでは、これまで有償版のGraalVMで提供してきた最適化コンパイラやG1ガベージコレクションなどを含むすべての機能が無料で利用可能となり、本番環境での利用も許諾されます。 Introducing a new distribution — Oracle @GraalVM! Use all the greatest G
書評「Kubernetes on AWS ~アプリケーションエンジニア 本番環境へ備える」は Kubernetes を中心に AWS も学ぶことができる良書 そろそろ Kubernetes 入門しようかな。インフラは AWS がいいな。 そんなあなたに Kubernetes on AWS ~アプリケーションエンジニア 本番環境へ備える ということで本日は 2020/03/25 に出版されたKubernetes on AWS ~アプリケーションエンジニア 本番環境へ備えるを紹介したいと思います。 こんな方にお勧め コンテナベースの開発プロセスや Kubernetes の基本的な使い方を理解したいアプリケーションエンジニアの方 Kubernetes は避けては通れないと思っている AWS エンジニア(インフラエンジニア)の方 Kubernetes を本番運用するにあたり何をすべきなのか知りたい
こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。 この記事では私が普段AWS環境を触るときに、ケアレスミスを起こさないために気をつけていることをまとめてみました。 あまり特別なことはしていないのですが、どなたかのご参考になれば幸いです。 普段行っていること ※ この記事ではミスしたくない/ミスできない環境を「本番環境」という表現で統一しています。 スイッチロール時に AWS Extend Switch Roles を使う 作業対象のAWSアカウントにログインする場合、IAMロールによるクロスアカウントアクセス(スイッチロール)という方法を利用しています。 スイッチロールの詳細については下記のブログで紹介しているので、スイッチロールって何?という方はご一読いただければと思います。 入社1年で変化したAWSサービスの使い方 スイッチロールを使う場合はデフォルトのマネ
このシリーズでは本番環境でのモデルの監視の必要性について考えていきます。全3回を予定しています。今回はその最初の回です。データの集計処理に不具合が発生してしまい、すべてのユーザーのログイン回数が0となってしまった場合に発生する事象について、ケーススタディとして見ていきます。 今回の要旨 機械学習を本番環境で用いる場合、モデルに投入するデータが壊れると結果が壊れる機械学習モデルの精度指標を監視するだけでは不十分なことがあるデータの型だけではなく、欠損を表す値の割合や値の分布の変化についても監視が必要TOC· はじめに · 主旨 · 前提: EC サイトのマーケティングキャンペーン · 背景 · 机上検証 · 評価結果 · ケーススタディ すべてのユーザーのログイン回数が0 · 問題発生 · 発生した事象 · 原因 ∘ 他チームの行った変更に対応できていない ∘ データの欠損について気がつけて
この記事は本番環境でやらかしちゃった人アドベントカレンダー20205日目の記事です。 去年の投稿を見て自分も過去色々やらかしてしまったなあという反省と懺悔の元今回参加させていただきました。 TL;DR 当時新卒1~2年目だった自分にあるミッションが課せられました。 当時関わっていたサービスに いわゆる一覧画面 + ページングで表示機能を実装している箇所がありまして、表示速度改善に取り組みました。 特に特定のカテゴリページの2ページ目以降の表示速度がかなり遅く、タイムアウトが頻発していたという状況でした。 Qiitaでいうところのタグフィードのようなものと思っていただけるとありがたいです。 何をしたか どの程度遅いかをまず調べようと、APIからDBに流れているはずのタイムアウトしているselect文をAPIと同様にRead Replicaにたたきました。 ちなみにデータベースはMySQLでし
課題 Lokiとはなにか? ログ転送の仕組み ログ可視化の仕組み 使ってみてわかってきたこと Grafanaでログをササっとみられるのは楽 『indexを作らない』の意味 ログから作成するメトリクスと統計情報 nginx-module-vts GrafanaのSlackが温かい 現在のLoki環境 VMの情報 コンテナの構成 負荷状況 今後 こんにちは!インフラユニットの小林です。 今回はログ監視ツール『Loki』の導入事例を紹介をします。 課題 これまでもログ可視化集約ツールを使っていたのですが、メモリ使用量の多さや気が付いたら落ちていたりして、VMのランニングコストや運用負荷が課題とされていました。 またUIが非常にリッチなツールだったんですが、我々のやる事と言えば『ApacheやNginxのログからステータスコードやリクエストタイムを可視化』したり、『アプリケーションでエラーが起きた
設計まとめ 改めて 実現したい環境と、その解決案をまとめます 原則、全インスタンスを 重要パッチを適用させている状態 としたい (ASGインスタンスも含む) → State Manager 関連付けを活用 定期的にパッチが当たるようにしたい → State Manager 関連付けを活用 事前にどのようなパッチが当たるかを判断するために、「スキャンのみ」も実施できるようにしたい → SCAN用関連付け、INSTALL用関連付けを作成。 PatchAssociationTask タグで分類できるようにする 検証環境/本番環境でパッチ適用タイミングをずらいしたい → STG用ベースライン、PRD用ベースラインを作成。 Patch Group タグで分類できるようにする 構築 Patch Manager ベースライン 以下のような CloudFormation テンプレートを作成して、展開しまし
これは Mercari Bold Challenge Month の3番目の記事です。 Mercari ではモノリスなサービスからマイクロサービスのアーキテクチャへと移行を行っている間、長期的な観点からみて、サービスメッシュの導入とその重要性を理解することが必要だと感じていました。ほとんどのインシデントレポートに対する現実的な対策としてあがるのが、レートリミットの導入、適切なカナリアリリースのフローの導入、適切なネットワークポリシーの導入などでした。そしてこれらこそがサービスメッシュによってもたらされる機能です。 前四半期では、私達はついに Istio の導入に挑戦することに決め、調査を開始しました。結果として、100 以上のマイクロサービスをホストするマルチテナント環境のシングル Kubernetes クラスタを深刻な障害を発生させずに本番運用を行うことができています。この記事では Me
こんにちは、ライクル事業部 エンジニアの菊池@kichionです 去年(2021年)からフロントエンド環境の立ち上げを行い、現在はバックエンドに戻ってきて技術負債の解消などを中心にシステム改善を行っています 現在システムのリプレイスなどでデータ設計から見直すこともあり、イベントデータをRDB(MySQL)のトリガーで生成しようと取り組んでいたところで罠のようなAWS RDSの仕様に引っかかってしまったのでその内容を紹介します 前提 AWS RDS(MySQL) バックアップ 事件 調査 原因 解決 検証 まとめ 前提 AWS RDS(MySQL) AWSで使えるRDBサービスです ライクルではデータベースエンジンでMySQL(Auroraではない)を利用しています 記事を書いている時点ではver 5.7.33を利用しています バックアップ AWS RDSではいくつかバックアップ方式がありま
MySQL互換のスケーラブルな分散DB「TiDB」、スマレジや@cosmeによる評価は本番環境のDBから移行可能、性能も十分高いと[PR] いわゆる「NewSQL」と呼ばれる、トランザクション処理を実現しつつも非常に高度なスケーラビリティを備えた新しい種類のリレーショナルデータベースが登場し、注目されています。その代表的な製品の1つが、オープンソースで開発されている「TiDB」(タイデービー)です。 TiDBはアプリケーションからはMySQLと同様にアクセスできるMySQL互換のプロトコルを備えつつ、TiDBを構成する主要な2つのレイヤである、SQL文を処理する「TiDB」とデータを処理する「TiKV」がそれぞれオンラインでのスケールアウトに対応することで、リニアに性能を拡張することが可能です。 1つのTiDBクラスタで400TB以上のデータ容量、1つの分散テーブル内で数兆行のデータを扱え
本番環境でやらかしちゃった人のアドベントカレンダーです。 2019 https://qiita.com/advent-calendar/2019/yarakashi-production 2020 https://qiita.com/advent-calendar/2020/yarakashi-production 例) 本番DB吹き飛ばした 本番サーバをデストロイした ネットワーク設定をミスって本番サーバにアクセス出来なくなり、サーバが世界から孤立した などなど... 以下の2点については必須項目なので、記述お願いします。 惨劇はなぜおこってしまったのか 二度と惨劇を起こさないためにどうしたのか もう二度とあの惨劇を繰り返さないために、みなで知見を共有しましょう。
スマートキャンプの笹原です。 みなさんはWebサイトの、特にフロントのパフォーマンス改善を日頃から行っていますか? 常に意識しているという方もいれば、気が向いたときにたまに見てみるなんてこともあるんじゃないかと思います。 今回はそんなパフォーマンスに常に意識を配れるように、毎日Lighthouseを叩いてみたのでその構成を紹介したいと思います。 Lighthouseとは 要件 処理の流れと制約 実際の構成 1. 定期的にCloud Tasksに各ページごとのTaskをEnqueueする TaskをEnqueueされるCloud Tasksのキュー作成 TaskをEnqueueするFunctionの作成 2. 各ページにLighthouseを実行しBiqQueryに結果を格納する 終わりに Lighthouseとは まずはLighthouseについて簡単な説明です。 Lighthouseとは
はじめに こんにちは、SREグループ 新卒2年目の佐藤です。 私が所属するSREグループでは毎週LT会が開催されています。 先日のLT会ではいつもと違う工夫がされていて、参加・発表のしやすさがグッと上がり、楽しく学びのあるLT会になりました。 そのLT会でされていた工夫は面白く再現もしやすいので、本記事でみなさんに共有します。さらに、実際のLT会の資料も公開します。MonotaRO(の1グループ)ではどのようなLT会が行われているかの雰囲気も知っていただければ幸いです。 はじめに スライド1枚で参加OKなLT会 どんな良いことが起こったか スライド大公開! 本番環境でやらかしちゃった選手権 この技術書がすごい!2023夏 感想 当日の感想スレッドの様子 さいごに スライド1枚で参加OKなLT会 私のグループでのLT会は週1で実施され、発表希望者がテーマを決め、資料を作成し、グループ内に発表
この記事は新野淳一氏のブログ「Publickey」に掲載された「個人開発者はRed Hat Enterprise Linuxを無料で最大16システムまで利用可能に、本番環境もOK。Red Hatが開発者向けプログラムの拡大を発表」(2021年1月22日掲載)を、ITmedia NEWS編集部で一部編集し、転載したものです。 米Red Hatはこのほど、個人開発者向けに提供している「Red Hat Developerプログラム」を拡大し、個人開発者には無料で最大で16システムまで本番環境でも利用可能にすることを発表しました。 これは先月発表された、CentOS 8のサポートを2021年末までとし、今後はCentOS Streamの開発に注力することへの影響を考慮したもの。 無料で本番環境を含む最大16システムまで利用可能 現在のRed Hat Developerプログラムは個人開発者に対して
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く