この記事では、自分が数年Site Reliability Engineering (SRE)を実践しつつ、SREについて考えてきたことをまとめる。 先月開催されたMackerel Drink Up #8 Tokyoと先日開催された次世代Webカンファレンス 2019では、SREについて集中的に議論する機会に恵まれたため、脳内メモリにキャッシュされているうちに、SREに関する私的な論考をまとめておく。 (以降では、SRE本の原著にならい、技術領域名を指すときはSRE、職種名を指すときにSREsと表記する。) SREとの関わり なぜSREに関心をもったのか 2015年にメルカリさんがSREチームを発足したときに、SREsの存在を知り、SREsはシステム管理者、Webオペレーションエンジニア、インフラエンジニアといった既存の職種を置き換えていくものだと理解した。 当時、自分が注目したのは、SRE
一休.comでWebフロントエンドを開発している宇都宮です。 先日、一休.comホテルページのスマホ版から、jQueryを取り除きました。jQueryを取り除いた経緯、やったこと、結果について書きます。 ちなみに、ホテルページには以下のURLでアクセスできます(スマホで開くか、PCの場合はUAをスマホに偽装する必要があります) https://www.ikyu.com/sd/00001290/ なぜjQueryを取り除いたのか? どうやったのか 何をやったのか jQuery.ajax() => fetch に置き換え fetchのpolyfillを採用した理由 DOM操作を標準APIに置き換え 要素の取得 show/hide addClass/removeClass html/text アニメーション $.ready() イベントフィルタリング jQueryの使用を防ぐ目印 jQuery削
Kubernetesのリアル Kubernetesでアプリ開発したことで、かえって今までより工数がかかっている。また、運用方法も今までと違うしベストプラクティスも少ないので本番稼働後も不安。そんな体験をしている人がそろそろ増えてきているのではないでしょうか。 実際、Kubernetesを実装しているIaaSの種類によって運用方法も若干違いますし、オンプレで構築する際も何のベンダーのソフトウェアを使うかで作法が変わってきます。また、進化するスピードも速いので、覚えたこともすぐ陳腐化する恐れがあります。 安定期に入るまでは仕方ないのですが、理想と現実は違うことは頭に入れておいた方が良さそうです。 Pivotalについて Pivotalという企業は日本ではあまり知られていないと思うのですが、クラウドの世界では有名な企業です。現在DELLの子会社であり同社が70%の株式を保有しています。同じくDE
こんにちは、freee 株式会社で CISO 兼 CIO をやっております。土佐です。 この記事は、裏freee developers Advent Calendar 2018 の 11日目の記事です。 当社は、クラウド会計freeeや人事労務freeeといったクラウドサービスをスモールビジネスのお客様向けに提供する会社です。クラウドサービスを提供する以上、我々自身もクラウドワークスタイルを体現しなければならないという、暗黙の認識が当社には存在していて、社内ITツールとして利用するもののほとんど全てが クラウドツール(SaaS)です。 クラウドツールを前提にした、IT投資の判断はそれまでのものとは異なるところがいくつもあります。それを踏まえて、クラウドツールの投資判断はどのようにすべきか、当社の経験から導き出された考えをご紹介したいと思います。 クラウドツールになってIT投資は何が変わった
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。言語サポート(Node.js)チームの伊藤(@koh110)です。 Node.js v10 も10月にLTSとなり async/await によるフロー制御は当たり前のように利用されるようになってきました。JavaScriptの非同期処理は async/await から覚える人も今後増えていくでしょう。今回はそんな非同期処理について、社内での事例を交えて記事を書いていこうと思います。 index Promise 化がなぜ重要なのか ユーザーに promisify をさせる落とし穴 Road to Promise まとめ Promise 化がなぜ重要なのか ちょうど3年前のアドベントカレンダーで、今後はいろいろなモジュー
大量生産のために一斉に同じことをするような仕事は減り、個々人の創造性やアイデアが求められる仕事が増えてくる中で、チームのマネジメントも変えざるを得ない。 計画した通りに手を動かしているかどうか管理するようなマネジメントから、個性や強みを活かしながら成果を出すマネジメントへの変化が求められる。その先にあるのが「チームの自己組織化」だろう。 ティール組織が注目されたのも自己組織化すれば、自律的に働きながらもチームとして成果を出せるかもしれないという期待からではなかったか。 しかし、チームの自己組織化を実現しようとしても、そう簡単にはいかない。自主性を重んじて、マイクロマネジメントをやめるだけではダメだ。なにより気をつけなければいけないのは、従来のパラダイムに引っ張られてしまうことだろう。 本稿では、自己組織化を妨げてしまう13個の古い常識や価値観について書いた。 1.計画通りであることを良しと
スクラム とは、最近、特にソフトウェア開発の分野でよく使われているバズワードです。この概念は、1995年のOOPSLAでJeff SutherlandとKen Schwaberにより提唱されました。自己組織的なチーム構成と短いスパンの持続可能な繰り返し作業に重点を置くもので、複雑なソフトウェア製品やプロジェクトを扱うためのすっきりとした軽量なフレームワークです。 シンプルで軽量な性質を強みとするスクラムですが、これを導入している企業の約半数が正しく実践できていないと思われます。では、一見すぐに使えそうな手法なのに、実践するのが非常に難しいのはなぜなのでしょうか。その理由と、これを確実に成功させるために講じるべき対策を見ていきましょう。 1. 組織の賛同が得られていない どういう タイプの企業であろうと、何かを変えようとすれば必ず直面する最大の課題であると言えるのが、これです。スクラムも例外
労働関係の法律を読んだりすると、よく「使用者」とか「被用者」とかいう言葉が出てくる。平たく言えば前者は経営者のことで後者は従業員のことなのだが、この言葉の背景にあるのは「使う/使われる」という関係であり、これを言葉通りに解釈すると仕事とは経営者の命令で「やらされている」ものということになる。 たしかに、仕事には「やらされている」と考えないと自分の中でうまく折り合いがつけられない要素も少なくない。毎日毎日、満員電車に乗って同じ時間に出社するのも、付き合いたくないクライアントにも精一杯の笑顔を作って対応するのも、締切に間に合わせるために終電ギリギリまで会社に残って仕事をするのも、仕事がある種の「義務」を伴うものであり、本当はやりたくないけどやらないと給料がもらえないからだ、という理屈に誤りはない。 もっとも、このように仕事を徹底的に「やらされている」と見ることに違和感を覚える人もいるはずだ。給
こんにちは、株式会社SCOUTERの開発責任者の小平(@ryotakodaira )です。 業務では、SARDINEという人材紹介会社向けの業務管理システムを開発しています。 自分の担当している事業では、metabaseというBIツールを使用して数値管理・可視化をしています。 そこで今回は事業全体にBIツールを用いた数値管理を定着させるまでの話を書いていきます。 BIツールとは簡単にいうとサービスのDBなどに蓄積されているデータを可視化するためのツールです。 BIツールの「BI」とは、「ビジネス・インテリジェンス(Business Intelligence)」を意味します。ビジネス・インテリジェンスとは、企業が日々蓄積されていく膨大なデータを分析し、その分析結果を経営意思決定に活用することをいいます。 このBIを助けるシステムを総称したものを「BIツール」と呼びます。 *1 metabas
Originally written in: English • Русский (авторский перевод) Translated by readers into: Deutsch • Español • Français • Português do Brasil • Svenska • Tiếng Việt • తెలుగు • 日本語 • 简体中文 • 繁體中文 • 한국어 Read the original • Improve this translation • View all translated posts 多くの人は、私が実際に持っている知識量より遥かに多くのことを知っていると思い込んでいる。それは悪い事ではないので文句を言っているわけではない。(世の少数派の人達は、努力して資格を得ているにもかかわらず、逆の偏見に苦しめられている。それはイケてない。) この記
はじめに サーバーのテスト自動化といえば、 Serverspec や Testinfra 、infrataster などが有名ですが、ネットワークのテスト自動化については、みんなが口をそろえて名前を出すものがないような印象です。一方で、リスクの観点から設定変更の自動化より先にテストや状態確認の自動化からはじめたいというケースもあるのではないでしょうか。 この記事では、どんなツールや組み合わせがネットワークのテストの自動化に使えそうかをまとめます。 ざっくりとした内容となっていますが、もし誤りや不足などありましたら @akira6592 までご連絡いただけると幸いです。 一覧 名前 タイプ 実機接続 主なテスト内容 言語 NetTester フレームワーク 要 物理ネットワークの受入テスト Ruby pyATS フレームワーク 要 疎通や show コマンド実行結果の妥当性 Python A
We're excited to announce that map and address-related searches on DuckDuckGo for mobile and desktop are now powered by Apple's MapKit JS framework, giving you a valuable combination of mapping and privacy. As one of the first global companies using Apple MapKit JS, we can now offer users improved address searches, additional visual features, enhanced satellite imagery, and continually updated map
// function.go package function import "net/http" func F(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Type", "text/plain; charset=utf-8") w.Write([]byte(r.Header.Get("X-Forwarded-For"))) } HTTP functions can be reached without an additional API gateway layer—Cloud Functions gives you an HTTPS URL. After the function is deployed, you can invoke the function by entering the URL
こんにちは! Air メイトのフロントエンドエンジニアの @sadness_ojisanです。今月から「React 人材をどう育むか」という連載を行います、この記事はその第一弾です。 みなさーん!React 人材の採用はうまくいっていますか???私たちはまだまだ足りていません! そこで最近では、React 人材を登用するために、採用だけでなく育成も試みています。 この連載では実際に行なった育成プランとその効果を紹介できればと思います。 私は社内で 2-30 人規模の React 勉強会の講師をしたり、社外でもプログラミング講座の先生などをやっています。 また、大学院では教育学を専攻していたこともあり、育成はかなり関心がある分野です。 この記事では、React 勉強会を開催しているなか、「この教え方や工夫が効いたよ」といった指導方略や、「受講生はここでつまづいたよ」という経験を紹介します。
By Connor Gilbert, product manager at StackRox Last month, the Kubernetes ecosystem was shaken by the discovery of the first major security flaw in Kubernetes, the world’s most popular container orchestrator. The vulnerability – CVE-2018-1002105 – enables attackers to compromise clusters via the Kubernetes API server, allowing them run code to perform malicious activity such as installing malware,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く