TISのリモートアクセスサービスでシステム障害、利用者数の急増が原因か 41
ストーリー by hylom
緊急時に使えないサービスとは 部門より
緊急時に使えないサービスとは 部門より
TISが提供するリモートアクセスサービス「RemoteWorks」で3月末にシステム障害が発生、4月13日よりサービスが停止しているという(TISの発表、日経xTECH、日経新聞)。これによって同サービスを導入している企業などで影響が発生しているという。
同サービスは自宅などの社外からオフィスの業務PCにアクセスするための機能を提供するもの(クラウドWatch)。同サービスは約400社が利用しており、登録されているユーザー数は約2万TISはシステム障害の理由として、利用者数の急増のためとしている。復旧は5月末の見込みという。
この停止期間の長さは何かおかしい (スコア:3, 興味深い)
https://xtech.nikkei.com/atcl/nxt/news/18/07614/ [nikkei.com]
> RemoteWorksを巡っては2020年3月26日にシステム障害が発生し、以降断続的に不具合が続いていた。
> 4月13日からはサービス停止が続いている。
> 原因についてTISは「利用者数の急増に伴い不具合が発生しているようだ」(広報)とする。
> セキュリティー面の脆弱性が存在する可能性も考慮に入れて、調査を進めているという。
※強調はAC
https://www.remoteworks.jp/support/page.html?id=00000082 [remoteworks.jp]
> 2020年4月16日
> RemoteWorksサービス(全ラインナップ)の提供を2020年5月末まで停止いたします。
> 調査の状況次第では、6月以降もサービスを停止いたします。
3/26にシステムがぶっ壊れた、それは仕方ないだろう。復旧の見通しが立たない、そういう事故もあるだろう。
だが2ヶ月、3ヶ月と復旧できない、原因すら分からない、「セキュリティー面の脆弱性が存在する可能性」って何だ?
3ヶ月あればモックアップの一つもでっち上げられる位だぞ。なぜ広報、営業担当者が原因を把握すらしていない?
例えば「3月末で退職したエンジニア以外にパソコンが分かる社員がいなかった」レベルの話じゃないかこれ?
Re:この停止期間の長さは何かおかしい (スコア:1)
なんかもうあからさまに「緊急事態宣言が終わってから直します」モードだよね
サービストップページの謳い文句「パンデミック/BCP発生時は出社せずに業務を継続」の空しいことったら
Re: (スコア:0)
データセンターに行ったら、ネズミが跋扈していたのかもしれないぞ。
※サーバーはともかくケーブルがランダムにやられていたら、全部張り直した方が早そう
Re: (スコア:0)
「サーバーラックの裏はネズミの卵でいっぱいだー!!」
Re: (スコア:0)
だれだネズミの卵で一杯だなんて言った奴は
一時帰休させるぞ
Re: (スコア:0)
最上段に神棚があったり
扉の裏側にお札(ITお守り)がびっしりと貼ってあったり
靴下が干してあったり
ぐらいしか面白エピソードはなかったですね
Re: (スコア:0)
こういう時は赤字覚悟で借金してでも(場合によっては経営者が身銭を切ってでも)修復しなければ次はないのに、
判断と覚悟が出来る経営者がいないんだろうね。
言ってみりゃ万一の補償に備えて保険料払ってきたのに、いざ事故ってみたら保険会社が保険金を払いませんでした
って事態なので、当たり前のように廃業に追い込まれることになる。
Re:この停止期間の長さは何かおかしい (スコア:1)
既にあかん感じのセキュリティー事故が発生してて調査してるとか。
発生してなくてもセキュリティー面の対応は時間かかるケースもありそうだ。
Re:この停止期間の長さは何かおかしい (スコア:1)
「喧嘩別れした元社員などが爆弾を仕掛けていた可能性」を「脆弱性」と呼んでいる可能性
Re:この停止期間の長さは何かおかしい (スコア:1)
コロナ禍がらみで3月中旬で派遣や請負を切りまくったけど、
システム全容を把握している人間はプロパー社員には誰も居ませんでした、というオチだったりして
Re: (スコア:0)
コロナ禍がらみで3月中旬で派遣や請負を切りまくったけど、
システム全容を把握している人間はプロパー社員には誰も居ませんでした、というオチだったりして
切った人を三顧の礼で呼び戻そうにも
出社禁止とか打ち合わせ禁止みたいなコロナ対策のための社内ルールで自縄自縛になって
連休明けまで身動き取れなくなってるんじゃないかと。
Re: (スコア:0)
その「三顧の礼」に手土産も持ってこないバカな企業ばかりなので、優秀な人材だと派遣元ごと縁を切って別の道に行くんだよな。
もしくは手土産を本人に渡さずネコババしてるか。
Re: (スコア:0)
それって広義の脆弱性ですけどね。真面目な話。
Re: (スコア:0)
「新規受注追加受注を停止します」ではなく「全サービス停止」だから本当に直せる人が居ないのかもね
Re: (スコア:0)
1週間前、Splashtop for CACHATTO(カチャット)も障害が発生していた (スコア:2, 参考になる)
4日連続障害発生のSplashtop for CACHATTO、無償提供によるユーザー急増が原因か | スラド Submission
https://srad.jp/submission/87333/ [srad.jp]
テレワークサービスの「Splashtop for CACHATTO(カチャット)」で4日連続障害発生 | スラド Submission
https://srad.jp/submission/87331/ [srad.jp]
テレワークサービスの「Splashtop for CACHATTO(カチャット)」で3日連続障害発生 | スラド Submission
https://srad.jp/submission/87318/ [srad.jp]
Re: (スコア:0)
昨日(4/20)も今日(4/21)も障害発生していますね。
CACHATTOサービス稼働状況 | CACHATTO
https://www.cachatto.jp/user/cfinfo/ [cachatto.jp]
2020-04-21
【Splashtop:復旧済み】 Splashtop for CACHATTO アクセス障害(2020/04/21 11:24 ~12:15)(クリックで詳細表示)
Splashtop for CACHATTOにおいて、アクセス集中が原因とみられる障害が発生しました。
■障害内容
接続元PC(テレワーク用PC など)から接続できない
接続
Re: (スコア:0)
2020-04-21
【Splashtop:復旧済み】 Splashtop for CACHATTO アクセス障害(2020/04/21 13:05 ~17:10)(クリックで詳細表示)
Splashtop for CACHATTOにおいて、アクセス集中が原因とみられる障害が発生しました。
■障害内容
接続元PC(テレワーク用PC など)から接続できない
■障害発生日時
2020年4月21日(火) 13:05~17:10頃に断続的に発生
■対
Re: (スコア:0)
午後から一切繋がらず仕事できなくなりました。明日は出社します。
サービス自粛 (スコア:1)
不要不急のアクセスを控えて貰えばよかったのにね
セキュリティ事象……… (スコア:1)
RemoteWorks サービス提供について(2020/04/20 17:00) [remoteworks.jp]
※太字は原文になし
処理能力 (スコア:0)
すぐに増強出来ないのか?
Re: (スコア:0)
データセンターを自前で保有していてクラウドサービスも提供している会社なんだから、サーバやネットワークの増強ができないってことは無いと思うんですがねぇ。
コロナ以前は保険のために加入していて使ってなかった企業も多かっただろうことを考えると、当初の目算から乖離しすぎてすぐには金が出せなくなってるんではないかと思います。
Re:処理能力 (スコア:2)
DCやクラウドサービスだって提供する側に物理的な設備があってこそだし、需要変動に応えられる余裕は残してあるといっても余裕を持たせすぎれば採算性が悪化する。
多くの利用者が同時にヘビーな使い方を始めた場合に備えられるほどの余裕があるとでも思ってる?
ましてやサーバやネットワークの物理的な増強となると機材調達に時間がかかる。こんな時期だから普段より調達が遅くなっても不思議はない。
うじゃうじゃ
Re: (スコア:0)
BCP対策を標榜して売ってるのに、そんな言い訳が通用するわけがない。
調達?んなもんカネさえ積めばAWSもAzureもGCPも即日貸してくれるぞ。
Re: (スコア:0)
Youtubeの画質下げるやつみたいに、データセンター側が増強できなくなってるところもあるんじゃないの?
不具合の原因を調査中ですが、調査に時間を要することが判明しております (スコア:0)
仕事にならないやんけ。これ契約破棄して、他社に乗り換えちゃうパターン?
※でも他社もパンクしそう
Re: (スコア:0)
何をどうしたら復旧に1ヶ月とか掛かることになるんだか・・・
Re:不具合の原因を調査中ですが、調査に時間を要することが判明しております (スコア:1)
4月に入ってから断続的に障害起きてるようだし、ハードだけではない根本的な問題あってまとめて修正しようってんじゃなかろうか。
Re: (スコア:0)
他社使えって書いてるくらいだから、もうあきらめてんだろう。
Re: (スコア:0)
SIerなんだから、あんまりブン投げるとTISの他の部門まで影響広がりかねないぞ。
ありゃりゃ、新型コロナウイルス感染者の発生について [tis.co.jp]かぁ(TIS社内には普段いない人だけど)。
Re: (スコア:0)
>お客様オフィス(東京都世田谷区)にて業務に従事している当社パートナー
ありゃりゃ、多重派遣ですか
Re: (スコア:0)
客先常駐の請負では?構築案件とかではよくありますが。
稼働率何割くらいを想定すればいいの? (スコア:0)
スポーツクラブでは幽霊会員も、頻繁に利用しない会員も多いので、
実際の会員数は施設のキャパを大きく上回るが、それでも問題なく運営できる
もちろん突然幽霊会員が熱心に運動しはじめると破綻するが普通そんなことは起きない
この手のサービスも、実際の利用率は少ないことを想定してキャパシティ設計をしてたんでしょう
Re: (スコア:0)
世の中サービスは全てそうじゃね?
MAX値なんて考えてたら経営できないし。
例えば保険も大体は死なないから、病気にならないから存続できてるわけで
仮に一斉に9割死んで保険金払ったら大赤字よ。
人口や死亡率から割り出した、採算を取れる保険料と、支払額で黒字になるラインを計算した上で決定してるわけで。
その計算に意味がないぐらいの状態になったそら破綻するよ。
単純に手数を増やせばゴリ押しできる業界ならまだしも。
Re: (スコア:0)
> 仮に一斉に9割死んで保険金払ったら大赤字よ。
もらう側の死んじゃえば払わないのでは? w
Re: (スコア:0)
保険金は受け取り人が死んでた場合相続人に権利があるから
辿れば誰かしらは大体受け取れるよ。
祖父母側、孫側に辿っても誰もいないって時には終わるけど。
サービスレベルで差をつけないの? (スコア:0)
たとえば、松・竹・梅の3プラン用意して、
松 稼働率100%を想定したキャパシティ設計
竹 稼働率10%を想定したキャパシティ設計
梅 稼働率5%を想定したキャパシティ設計
みたいな3パターン用意して、それぞれ価格差をつけておく
今回みたいな非常時は、梅プランの人は利用不可、竹プランの人はたまに利用できる、松プランの人は全員利用できる、みたいな
最近はアメリカのクラウド業者は、安価なプランだとサーバ足りないときは使えなかったりするよね
混雑時でも使える高いプラント差別化をはかってる
Re: (スコア:0)
>
最近はアメリカのクラウド業者は、安価なプランだとサーバ足りないときは使えなかったりするよね
混雑時でも使える高いプラント差別化をはかってる
SFだけどそんな設定あったな。死後もソフトウェア化した状態で生き続ける人がいる時代で、富豪は専用サーバーを確保しているから現実世界とコミュニケーションできる速度で計算されるのに対して、貧乏人は入札で決まる計算リソースで時々しか計算されないので、速度差が大きすぎて、現実世界から切り離されてる。
Re: (スコア:0)
micro instanceそのものですね。
Re: (スコア:0)
でもリザーブドインスタンスは優先確保だけど割引が効くという不思議。
固定確保なので当たり前といえば当たり前ですが