オフィス移転・開設に伴う社内インフラ関連作業をまとめてみた｜吉田航
元同僚から「オフィスを増床（＝移転or新設）する場合、社内インフラってどうすればいいの？」と質問を受けることが多いので、一連の流れをまとめてみました。 私自身もはじめて担当した時は右も左も分からずに苦労したので、未経験で困っている方の助けになれば幸いです。 ■前提・「物件の選定・契約が完了した時点」を起点とし、情シスの実務的な観点 で書いています（登記や各種届け出など総務的な内容には触れません） ・物件の選び方、コスト、オフィスデザインなどについてはそれだけで 大きなトピックかつ情シス専門外の内容になるので今回は触れません ・数千人規模のオフィスや自社ビルではなく、数十名～数百名規模の 賃貸オフィスをターゲットにした内容となっています ■知っておいた方が良い専門用語初めてオフィス増床関連の打ち合わせに参加した時は、 「B工事…？OA床…？欄間…？EPS…？」 と専門用語の嵐でちんぷんかんぷ
障害から学ぶクラウドの正しい歩き方について考える - そーだいなるらくがき帳
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
SRE風のインフラエンジニアにならないために - Work Records
この記事は、SRE Advent Calendar 2018 - Qiitaの24日目として投稿しています。 SRE風のインフラエンジニア SREとDevOps そもそもDevOpsとは SRE本でも取り上げられている、DevとOpsの目的の差異 ミクロなDevの目的 ミクロなOpsの目的 Ops側の視点での安定性の考え方を改める システムを高速に更新可能にしておくことで安定性を担保する インフラエンジニアではなくSREとしてどう高速リリースを実現するか プロダクトの高速リリースに効くところを見極める リリースするにあたっての心配事を潰す 開発チームが自律して動ける仕組みやツールを提供する 今の組織でやれていること 開発チーム出身の人がSREチームにジョインしてくれている SREチームに入る新人のエンジニアさんもRails研修などを通して最低限の開発力を持っている SREチームのケツを叩い
Well-Architectedな組織を実現するためのチャレンジ
この記事は、CyberAgent Developers Advent Calendar 2018 13日目の記事です。 はじめまして、技術本部サービスリライアビリティグループ（以下、SRG）の柘植（@shotaTsuge）・岡田（@rm_rf_slant）です。 今回は、我々が組織という観点で行なっている活動について紹介したいと思います。 SRGとは はじめに私達の組織についてお話しします。 私達が所属している技術本部のSRGは、メディア管轄（AbemaTV 関連事業以外）と呼ばれる主に、Amebaサービス（アメーバブログやアメーバピグなど）や子会社が提供しているAWAやタップル誕生、技術本部が運用しているアメーバの基盤サービスや秋葉原ラボなどのインフラ周りを横断的にサポートする部署です。 SRG が普段行なっている業務としては、新規サービス立ち上げのインフラ周りのサポートや、既存サービス
https://blog.animereview.jp/zero-trust-architecture/
シンジです。社内インフラを構築するとき、何を指標として設計しているか、何のために作るのか、誰が嬉しいのかを考えずに淡々と予算を投入している企業の多いこと多いこと。これから会社を作るならまだしも、既存企業は長年の蓄積があるわけです。物理機器や、買収合併の弊害、シャドーITに働き方改革推進の圧力。これらに個別的に対処することこそが無駄かつ自己満足なので、自社のインフラはどうなるべきだったのかを考えたい物です。 ITは企業にとってコアである 企業や組織運営において、ITを使うことで便利になったり、効率が良くなったりする程度の時代はとっくに終わっています。企業や組織からIT全てをとっぱらってしまうと、企業や組織が消え去る可能性が非常に高い、というか確実に死ぬであろう状態にまでITに依存しています。つまり現代においてはITはコアなのです。 情報システム部門はその重要性を理解していない 企業においての
インフラエンジニアからSREへ ～クラウドとSaaS活用が変えるサービス運用のお仕事～ - 一休.com Developers Blog
2018年4月、データセンター完全クローズ 一休は、今年の4月にデータセンターを完全にクローズしました。現在、すべてのサービスをAWSを使って提供しています。 この過程で各種運用ツールやビルド/デプロイのパイプラインなどをすべて外部サービスを使うように変更しました。 これによって、インフラエンジニアやサービス運用担当者の役割や業務が大きく変わりました。本稿では、その背景を簡単に紹介したいと思います。 ざっくり言えば、 物理サーバのセットアップ&データセンターへの搬入のような仕事はなくなった。 アプライアンスの保守契約、パッチ適用、運用ツールのバックアップのような仕事もなくなった。 各種メトリクスを見ながら、Infrastructure as Codeでクラウドリソースの管理や調整をする仕事がメインになった。 必要に応じて、プロダクトのソースコードに踏み込んで必要な改修を行い、サービスの安定
ASCII.jp：AWSをやめたDropbox、自社DCに移行した背景とメリットを語る
2018年8月30日、クラウドストレージサービス「Dropbox」を展開するDropbox Japanは、グローバルのストレージインフラやネットワークについての説明会を実施。AWSにあったシステムを自社データセンターに移した背景やそのメリットなどをDropbox Japanの保坂大輔氏が説明した。 エクサバイトに向け加速度に増え続ける超巨大システム Dropboxを支えるテクノロジーについて説明した保坂氏は、まずDropboxのサービスのスケール感について説明した。Dropboxが展開されている国は現在180以上で、登録ユーザー数も5億人以上になる。このうち1100万におよぶ有料ユーザーの80％以上はDropboxを業務で利用しており、個人向けサービスのイメージからは脱却しつつある。実際、日本でも関西大学やアディダスなどが万単位のアカウント数で運用しているという。 顧客データも1エクサバイ
インフラCICDの勘所
Kubernetes 疲れに Azure Container Apps はいかがでしょうか？（江東区合同ライトニングトーク 発表資料）
失敗しないデータセンター設計のためのケーススタディ - Qiita
IaaSの中で構築などをしている者です。 データセンターの中にネットワークやサーバを作っていますが、データセンター設計1にはこれといった指針やベストプラクティスのようなものが（あるようで）実はあまりないため苦労することがあります。 検証環境でもない限り、データセンタに作ったシステムというのは、気に入らないからと言って、じゃあ止めて作り直すね、というわけにもまいりません。 特に物理的な問題は、後になってから「ああしておけばよかった」と思っても、後の祭りです。 クラウドを使っていれば、気にしなくても良いのですが、それでもコロケーションやオンプレミスに何か作らなければならなくなった方の参考に少しでもなればと思い、まとめます。 サーバとルータを同じラックに入れるのは有りか？ 何が問題なの？と思われるかもしれませんが、 結論を言えば、無しではないが極力避けるべき、です。 主な問題はこんなところです。
1万台のサーバを監視できると話題のPrometheusをGrafanaと組み合わせて導入した話 | Nagisaのすゝめ
はじめに 初めまして、下記の記事にて紹介がありました インフラエンジニアの榎戸です。 golangを使って開発したWebAPIを1年半運用して改善してきたことー月間20億PVのマンガサービス開発の裏側 場数を踏んできたのかは分かりませんが 笑 23歳エンジニア歴は２年と浅めです。 まだまだ未熟なエンジニアですが 今回はPrometheus + Grafana について紹介させて頂きます。 内容については下記となります。 Prometheus導入の経緯 Prometheus概要 Prometheusでの監視構成 次回お知らせ それでは始めていきます。 Prometheus導入の経緯 まずPrometheusを導入した経緯について少しだけ触れたいと思います。 弊社では月間20億PVのマンガサービスやそれと並行して走っているマンガサービス、また動画配信サービスや、アプリゲームの配信なども行なって
インフラエンジニアのこれまでとこれから
インフラエンジニアのこれまでとこれから1. © 2017 Groovenauts,Inc. インフラエンジニアの これまで と これから 株式会社グルーヴノーツ 熊野 良(Ryo Kumano) Developers Summit 2017 KYUSHU #devsumiB B-5 2. © 2017 Groovenauts,Inc. はじめに 本スライドは公演後にインターネットで公開予定です 公演中の撮影・SNS投稿はOKです ハッシュタグは #devsumi #devsumiB となります ご質問などは公演後の Ask The Speaker スペースで 3. © 2017 Groovenauts,Inc. 本発表における「インフラエンジニア」の定義 システムにおけるサーバ・ネットワークなど 『システム基盤』への作業を実施し、責任を持っている人を本スラ イドにおける インフラエンジニア
新メール配信基盤への移行 /ikyu-mail-platform - Speaker Deck
一休✕bitFlyer C#をつかったサービス開発の裏側 https://ikyu.connpass.com/event/35161/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
インフラエンジニア エボリューション ～激変する IT インフラ技術者像、キャリアとスキルを考える～ at Tech Summit 2018
強いインフラが組織を創る / #jtf2018
AWS費用と戦う
本当は恐ろしい分散システムの話
インフラエンジニア必見！勉強会の歩き方
【freee×プレイド】Tech Meetup 〜インフラ監視編〜を開催しました！
インフラ野郎Azureチーム Night
はてなのインフラ環境を自宅で再現する
