システム運用はお金で解決したい、ができなくなってきている - orangeitems’s diary
ビジネスは基本的に成長していくものだし、拡大していくことが前提で、しかも最近だと「システム」が付いてくる。全部人力で作り上げるビジネスなんてあるのか。いや、ない。あるとしても小規模だろう。人だけで成り立つなんてビジネスを放置しても、きっともはや、人が集まらない。コンピューターによる自動化はない。全部人力だ。さあ仕事しなさいって、それは原始的だろう。あらゆる仕事場で自動化ありきの人間の仕事が増産されているのであり、人々もそういう職場を狙っている。時代遅れの職場で、かつそういう人力の仕事は生産性も低く給料も安いので、どんどん敬遠されるようになる。 さて、じゃあシステム化しました、と。システム化するための要員はまだいるようだ。各社ベテランが腕を奮っている。DXの掛け声でクラウドもあって生産性は上がり、システムと名の付くものが量産されている。わかっている、システム構築のスピードは10年前と比べると
インフラエンジニアになるのは簡単か - orangeitems’s diary
Q. インフラエンジニアになるのは簡単か？ A. 簡単です。 インフラエンジニアでベテランの私でもこう答える。 ただし、なることと、上を目指すのは全く別のお話だ。インフラエンジニアを名乗ること自体は簡単でも、何を仕事にするかは恐ろしく幅が広い。 幅が広いから、スキルの表現が標準化されていない。何でもできるをフルスタックというのは簡単だけど、何がフルなのかを表現できる人は誰もいない。 自分はフルスタックだ、と言う人がいれば、それはあなたが働く現場の全ての業務、という意味でのフルであって、世の中の全ては捉えきれてはいない。 もはや、全てを知っているというよりは、未知なことがきてもなんとかできる、という意味合いの方がインフラエンジニアについては当てはまる。どんな要件が来ても基盤となる知識があるので、資料を読み解けば何とかできる、ぐらいの胆力が求められる。 未経験からのインフラエンジニア、という意
インフラエンジニアが要らなくなる方法 - orangeitems’s diary
定期的に、将来インフラエンジニアは要らなくなるという意見を見る。そもそも、IT業界の中であまり人気のないこの職種。しかも将来性がないとまで言われるとますます、なり手がいなくなるよと思う日々である。誰だそんな記事を今日も書いているのは。 それならそれで、インフラエンジニアがいなくても仕事が進められるようにならんかと考え、省力化について試行錯誤するわけである。少し前に話題になったコンテナ化やマイクロサービスが、今のAI並みに業界で話題になった時には少しワクワクした。もう開発者側で、複雑なネットワークの調整、ロードバランシング、その他やってくれるかと思ったものだが、残念ながら現状をそうはなっていない。 むしろ、その辺、うまくやってくれませんか、みたいな相談を開発者から受けるたびに思う。課題は存在し続けている。課題を今まで縦に切っていたのを横に切ったとしても、何にも解決しない。今まで縦に切ってまし
インフラの話をすると黙り込み面倒な顔をするエンドユーザーの仕組み - orangeitems’s diary
エンドユーザーがシステムを発注する際の動機は「システムを使いたい」しかないと思うんだよね。 インフラエンジニアやると思うのが「エンドユーザーはなんでシステムを使いたいだけなのに、データセンター、ハードウェア、OSやミドルウェア、監視、バックアップの話を合意しなきゃならないの？」ってこと。 SaaSを選ぶエンドユーザーの気持ちがわかる。 — orangeitems🍊 (@orangeitems_) August 11, 2022 でもシステム構築の一部始終を見た人ならわかるけど、システム単独で動くことはない。 ・アプリケーション ・ミドルウェア ・OS ・仮想基盤 ・ハードウェア ・ネットワーク ・データセンター ・監視 ・バックアップ ・運用体制 システムが動くまでは上記のような要素が一部、もしくは全部組み合わさっていて、どこかに考慮漏れがあると正直に動かなくなるという厄介な性質がある。
本当の意味でモバイルできるノートPCに出会ったことがない - orangeitems’s diary
モバイルノートってのは運用をやっている人間にとっては昔からキーアイテムで、システムは24時間いつでも動いているので、担当者の人権なんて知ったことではない。眠るとかレジャーするとか、当たり前のようにされていることすら場合によっては侵食してくる。特に場所の移動は大変で、今でもデータセンターの500m以内に住んでいる方はいらっしゃると思う。クラウドの時代ではインターネットさえつながればなんとかなるので少しは制限が無くなったが、それでもスマホで対応するのはほぼ無理。リモートデスクトップやVPNはできるけど、対応できるような操作性じゃない。となると、モバイルノートパソコンが必須となる。 で、モバイルノートパソコンさえあれば・・と思うが、現実は厳しい。今や連続稼働14時間とか20時間とか、スペック上は外出中電池切れの心配ないじゃん、と思っても、ちょっと会議室に連れ出してWeb会議して。終わるころにはバ
LINE Pay決済情報がGitHubに流出する件は防げたのか - orangeitems’s diary
LINE Payの件、ご存知かとは思いますが、こんなことが起きています。 linecorp.com このたび、ソフトウェア開発のプラットフォームである「GitHub」上で、一部ユーザーのキャンペーン参加に関わる情報が閲覧できる状態になっていました。 閲覧可能となっていた情報に、氏名・住所・電話番号・メールアドレス・クレジットカード番号・銀行口座番号等は含まれておりません。また、現時点でユーザーへの影響は確認されておりません。 本件につきまして、下記の通り報告いたしますとともに、ユーザーおよび関係者の皆さまに多大なるご迷惑とご心配をおかけする事態となりましたことを、心より深くお詫び申し上げます。 現在、閲覧できる状態にあった当該情報は削除し、該当ユーザーへの通知を行っております。 情報の中身はどんな言い訳をしようと決済関連の情報であり、このようなシナリオでの流出は金融に携わるのであれば決して
システム運用の超えられない壁 - orangeitems’s diary
今日とても面白い気づきがあった。 システム運用の現場で、毎朝、アラート確認を行っている。どこでもやっていることだと思うが、業務時間外に出力されたアラートを毎朝確認し、対処が必要かどうか判断する。軽微なものまで目を通し、障害予兆を見逃さないのはとても大事な仕事だ。 あるアラートに対して、メンバーが確認をし、システムオーナーであるお客様に情報提供を行った。行ったのだがその文が私は気に入らなかった。「アラートが出ていますので、方法Aや方法Bなど、対応を検討ください」といった文だった。 お客様はシステム運用の専門家ではないので、これじゃ情報は足りない。自分がお客様としてこれを読んだ時に全部わかるのだろうか。わかるためにはもっと付加するべき情報、例えばアラートの意味。なぜこういうアラートが出るにいたったのか。もし放置するとどうなるか。必要な情報をわかりやすく伝える必要がある。 まずは見本を見せようと
内製化は、きっとうまくいかない - orangeitems’s diary
最近はDXという言葉が独り歩きしてしまい、結局はどうすればいいのかと考えたあげく、内製化に舵を切る企業が多いと聞きます。 でも、この内製化、非常に危ない面を持っていると思っています。結局はユーザー企業が、SI部門を自前で持つということにほかならないからです。このSI部門、立ち上げるときにはだいたいが、大手のSIerが出身で、それまでの知識や経験をもとに組織を組み立てるのが通常です。 これ、はじまりはうまく行くんです。むしろ、一から作ったのでSIerよりもスマートに内製をスタートできる場所もあるぐらいです。そう、そこまではよい。問題は、この内製化部門が成長できるかどうか、です。 SIerはいつも競争にさらされていて、いつでも新しいトピックを主にアメリカから輸入し、常に最新化、モダナイズしないといけない強迫観念を持っています。 過去、外資のベンダーのイベントが都内ホテルであったときに、基調講演
SSLサーバー証明書は2年物を買ってはいけない - orangeitems’s diary
SSLサーバー証明書は2年物を買うべきではない 今日の今日、今の今知ったことですが、たくさんの人に知られるべきだと思ってまとめます。サーバー証明書を購入する時、たいてい「１年」「２年」が選べると思います。更新作業は面倒なので、２年を選びたくなる方がいらっしゃると思いますが、この「２年」に大きな落とし穴があります。端的に言えば「１年」を購入するべきです。 その理由は、AppleのSafariにあります。 その理由 下記の記事を見てください。 ssl.sakura.ad.jp AppleがSafariブラウザにおいて、2020年9月よりSSL証明書の最大有効期間を398日に短縮すると発表しました。突然発表された本対応の経緯やその影響、私たちがこれから取るべき対策についてご紹介します。 Appleの発表は2020/3/3です。もう一か月も経過するのに結構誰も知らないのではないかと思います。最近の
「なぜ動くか」に興味を持たない技術者が増えている憂い - orangeitems’s diary
なぜ動くか？ ここ最近、技術者と名乗る人々と会話して思うのが、「なぜ動くか」ということを知りたいという興味が失われているということです。 問題 例えば、下記の書籍を紹介します。 「ネットワークはなぜつながるか」という本で、あらゆる技術者に読んでほしいと思っています。目次は以下のようになっています。 ブラウザにURLを入力してからWebページが表示されるまでの道筋をたどりながら、その裏側で働くTCP/IP、LAN、光ファイバなどの技術を説明していきます。インターネットを通ってサーバーまで行って帰ってくる道筋の途中には、今のネットワークの主要な技術要素が全部あります。そこでの機器やソフトウエアがどのように動き連携しているのかを探検すればネットワーク全体の動きがわかります。 第2版では、全体の構成を見直し、探検の途中で、今、ネットワークのどの部分にいるのかを明確にしました。また、各技術の基本的な
ストレージはこわいよ - orangeitems’s diary
ある夜起こったどこかの会社の話 夜も更けた午前3時半ごろの思い出。 オンプレミスでの仮想基盤。いくつものシステムが動いていたのですが突然、この時間に複数のシステムエラーを感知。 電話で連絡が来るようになっていたのですが、あっちもこっちもそっちもどっちもアラートなので何が何だかわからなくなります。 運用設計なんて、特定のシステムがエラーとなったときのことしか考えられていないので、十も二十も同時にアラートになったら破綻します。電話連絡ったって電話は１つしかないので、担当者にはつながらなくなります。 私は運用の場面ではリーダーだったので、メンバーからエスカレーションを受けます。あっちも、こっちも、そっちもエラーですと。何が起こってるの？、わかりません。 眠気なんて一気に吹っ飛ぶのですが、一方で世の中の終わりを悟ります。 例え、この窮地を切り抜けたところで、たくさんの恒久対応までの道のりと、謝罪行
Kubernetesの自前運用はやっぱりツライらしい - orangeitems’s diary
Kubernetesの自前運用は難しい これから嫌でもコンテナと戦わなければいかないインフラエンジニアには何度でも読み返してほしい記事です。 www.atmarkit.co.jp はてなのMackerelチームはKubernetesクラスタを自前で構築して運用していたが、撤退を選択したという。なぜ、Kubernetesの運用を諦めて撤退を選んだのか。はてなのMackerelチームでSREを務める今井隼人氏が語った。 考察 この話、20年前のLinux草創期を思い出すんです。 雑誌の付録にLinuxがCD-ROMで付いてたんです。最近のスマートなCentOSとかじゃなくてですね、何Linuxだか忘れたのですがインストールも含めて3日間ぐらいかけて取り組んだんですが結局失敗した記憶があります。 これからKubernetesなりコンテナがやってくるのはここ最近に書いた通りで、早くそっちの世界に行
Kubernetesはまだ成功していない - orangeitems’s diary
Kubernetesの読み方 Kubernetesと書いて、どう読むでしょうか。 登場時には、クーベルネイティスと読む人やクーベネティスと読んだり、いったいなんて読むのが正解なんだろうと悩んだままなんとなくクーベルネティスがいいかななんて思っていました。 今日、日経にこんな記事が出ました。 www.nikkei.com ・・・その主役は、グーグルが開発した仮想化ソフトの運用ツール「クバネティス」・・・ クバネティス！！！。また新しい呼び方ですが、日経に出たということは今後は経営層はクバネティスと言ってくるはずなので、少なくとも日本国内では、く・・くばねてぃす・・と呼ぶことにしようと思います。 Kubernetesはまだ成功していない 国内のメディア記事を読む限り、結構たくさんのワークロードがKuberenetesで動くようになってきたように思います。特に大量のコンテナで分散処理する必要があ
インフラエンジニアの独り言、ストレージは盲点になりがち - orangeitems’s diary
インフラエンジニアの世界 IT技術者というと世間から見たら、要件定義やシステム設計をおこなうシステムエンジニアと、それを実装するプログラマーしか見えてないと思うんですよね。でもその基盤を動かすインフラエンジニアという人たちが全体の10パーセント弱（肌感）存在しています。 インフラエンジニアと言ってもまたそこから役割分担があって、物理サーバーやOSに強いサーバーエンジニアと、ネットワークに強いネットワークエンジニアがいます。大昔は物理サーバーとネットワークしかインフラに無かったので、大体はこの二極化でした。ネットワークエンジニアはスイッチやファイアウォール、ロードバランサーくらいまでは自分の領域としてくれていますが、OSやミドルウェアのことになると、それは私の領域ではない発言が出てサーバーエンジニアをブチ切れさせること請け合い。逆にネットワークエンジニアはサーバーエンジニアがなんでもネットワ
AmazonのDNSトラフィック乗っ取り 仕組みについて解説 - orangeitems’s diary
Route53のトラフィック乗っ取り AmazonのRoute53がトラフィック乗っ取りの被害に遭った、と聞くとぎょっとした人が多いのではないでしょうか。AWSの利用者は多いですからね。攻撃の仕組みについて解説します。 www.itmedia.co.jp AWSのクラウドベースのDNSサービスである「Route 53」のDNSトラフィックが何者かに乗っ取られ、「MyEtherWallet.com」のユーザーが仮想通貨を盗まれる事件が発生した。 解説 まず、この問題に関して利用された攻撃手法は「BGPハイジャック」という名前であることをおぼえてください。BGPとはネットワークの中で、ルーティング情報（経路情報）を交換するためのプロトコルです。BGPにて世界中のルーターが会話をすることによって、世界中どんなところにでも、インターネットがつながっていればパケットを届けることができるのです。例えば
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
