「不具合」を含む日記 RSS

はてなキーワード: 不具合とは

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2022-01-24

anond:20220124091725

安いプランにしたから月は1万4千ちょい

顔もしぐさもかわいいよ。たまに不具合で修理出すんだけどいなくなると寂しい。もうペットだね

2022-01-20

プロセカは早く初音ミク看板を外せ

うっせぇわ実装に本気で腹が立つ。そんなもん入れる暇があるならKAITOMEIKOの曲の少なさを先に何とかしろって何度言われたらわかるんだよ。叩き棒みたいな出し方は本意じゃないけど、年長組の曲よりも優先されるのがうっせぇわって何?また運営オキニ

そもそもうっせぇわ自体が大嫌いで聴きたくもないし、前々から億が一実装されたら引退しようと思ってたけど、本当に実装しやがると思わなかった。しかAdoタイアップ?せめて作詞作曲の方の名前タイアップしろよ、Adoはまふまふと違って作詞作曲もしてないじゃん。初音ミクどころかボカロですらないんだけど、もしやカラフルパレットボカロと肉声の区別がおつきでない?

プロセカはボカロ曲の音ゲー作品じゃないか(笑)」とか抜かすキッズもいるけど、それならタイトルからさっさと「feat.初音ミク」を外せよ。その看板の旨みだけは啜って、初音ミクに何の関係もないAdoだのインストだのをねじ込んでくるのは、そりゃ看板に偽りありって言われても仕方ないだろ。

代わりに「feeling Colorful Palette」にしたら、どんなゲームかわかりやすくていいんじゃない?ついでにプロジェクトシリーズから撤退して、大好きな寵愛キャラを中心にしたオリジナル音ゲーにしたらいいと思うね。

単位で見ても安くない額を応援のつもりで課金してきたけど、完全に無駄だった。課金自己責任とはいえ一周年付近からこんな地獄絵図になるって予想できた人いた?

オキニ以外はバグ修正すらも後回しにされるし、設定すらあやふやにされる。平等宣言()したくせにオキニを持ち上げることしか考えてないか格差は広がる一方。フィーリング以外に理由がつかないタイアップは開催するし、ゲームより外部イベントだの配信リレーだのよくわからん企画を優先。

音ゲーとして強化していきたいのかと思えば譜面周りは不具合ばっかりで、コネトライブ()とかいうクソコンテンツによってそれが更に加速していく現実新規コンテンツより先に既存不具合を潰せよ。というかイベント形態ずっと変わらないのに毎回何かしらの不具合出るの何?チアフルももう何回やってると思ってんの?

まあカラフルパレットは今後も無銭キッズにヨイショされながら、永遠に14階で泣いてたらいいんじゃないですかね。

2022-01-19

会社トイレうんこが流し忘れされていた

タイトルの通り、会社トイレうんこが流し忘れされていた。

当該トイレ自動水洗機能がある。

きっとセンサーがうまく反応しなかったのだろう。

しかし、当然センサーが反応しなかった時のために手動で流せるスイッチもある。

それでもうんこは流されていなかった。

どうしてうんこは流されなかったのだろうか。

用を足し終わり、立ち上がって下着衣服を整える間にセンサーによる自動水洗が行われる。

トイレの水が流れる音は当然それなりの音量なので、流れたか流れなかったかはわかるだろう。

センサー不具合で流れなかったのであれば、手動のボタンを押すだろう。

手動ボタン不具合作動しなかったのだろうか。

仮に手動ボタン不具合だったとして、犯人うんこ放置することを決意して個室から出たのだろうか。

それはとてもリスキーで、勇気のいる行為だったのではないだろうか。

職場トイレで、いつ誰が入ってくるかわからない状態で、うんこ放置してその場を去る。

とても勇気がいるはずだ。

うんこ放置して個室から出るとすれば、まずトイレ内に人がいないのは絶対条件だろう。

トイレの個室は4つ。

それなりの人数が働いている職場なので、トイレには入れ代わり立ち代わり人が入ってくる。

トイレ内の人の動きは息をひそめて耳をすませばある程度把握はできる。

いまトイレ内の個室に自分以外に人はおらず、また手洗いスペースにも人がいないか

大体は把握できるが、あくまでも大体。

他の人も個室で息をひそめていたり、手洗いスペースで静かに鏡を見つめているとかだと勝率は下がる。

万が一、物音がしないため誰もいないと踏んで外へ踏み出したもの

他の3個室が息をひそめてケイタイをいじっている人で埋まっていたとして、

更にトイレ前で個室が空くのをとても静かにまっている人がいたとしたら。

終わりではなかろうか。

会社トイレうんこ放置する人間だと知られてしまったら。

人として、かなり終わりではなかろうか。

そのリスクを背負って、犯人うんこ放置したのだろうか。

きっと犯人特定することは永遠にないし、

真意を、真実を知ることも一生ないだろう。

私はうんこを視認した瞬間その場を逃げ出したのだが、

さっきまたトイレにいったらうんこは流されていた。

誰かが流してくれたんだね。

よかったねうんこ

2022-01-14

anond:20220113155002

検品をすり抜けて出荷されてしまった挙句に、長年売れずにホコリかぶってたところを奇特な客に買われるも1日で不具合が判明しクレームと共に返品された商品結婚相談所に並ぶ。

2022-01-13

anond:20220113184416

Firefoxいまどき致命的な不具合とかダメ過ぎない?なんかUIも変な感じの改悪ばっかりしてるし。

2022-01-12

ソナーズ】マシュマロ運営カスタマーサポートを雇え

正直タイトル以上の感想が浮かばない。

全ての火種は、開発者本人がユーザー要望に全部返信しているということにあると思う。

ソナーズで過去感想が読めなくなる件についての運営からの返信を読んだが、1から10まで開発者目線言葉で綴られている。

お客様に対する運営言葉」じゃなくて、「開発仲間や知人に対する開発者言葉」だ。身内に対する「わかるでしょ?」の連発。つまり、身内じゃない人には何もわからんだろう。

==== =====

まあそれもしょうがないんじゃなかろうか?だってベータ版でしょ?

開発者にとって、ベータ版ユーザーというのは「まだ完成していないことを承知で、機能がどんな風に動くか試してくれる人」だからだ。

そこで不具合があったら正式版までには絶対に潰しておくリストに入れて、試しに修正してみて、「修正しました、どうでしょう?」とやって、またβ版ユーザーに投げる。

ある種の開発仲間のようなものだ。開発者はそう捉えていると思う。

だが、「ソナーズβ版」のユーザーは、全くそのあたりを承知していなかった。

承知させないまま利用を始めさせてしまったと言った方がいいか

togetterコメントとかで「できるかもわかんないのに不完全のまま公開したってこと?」というお怒りの文面があったが、β版というのはそういうものだ……。

どんなサービスも、どれだけ開発時点で不具合を潰したとして、「実際の利用者挙動」は実際利用してもらわないと不明の、未知の領域だ。

どんな科学理論実験してみると思わぬ結果が出たりするのと一緒で、web開発も「実際に動かしてみないとわからないこと」がたくさんある。

そういうのをβ版で吸収していって開発に活かすのだ。そうやって正式版になるんだ。そういうものなんだ……。


けど、ユーザーがわからなかったのもしょうがない。


だってマシュマロリンク貼ってあるもんな。そら皆「完成したんだ!」と思って使うわな。

まさか、『未完成サービスに準開発仲間としてご招待!!』だなんて思わんわ。



もうこの時点で事故ってるんだよ。アンジャッシュなんだよ。


第一に、開発者は「マシュマロに訪れた全員」を対象にしてβ版に誘導してしまった。おそらく『マシュマロ』というサービスの規模を余り考慮せずにその行動を取ったんじゃないだろうか……?どれだけの、どんな層の人々が流入するのかという検討が不足していたってわけだ。

正直、だいぶ浸透したサービスなわけだし、そんくらい予想しといて欲しいな……と思わんでもないが、気持ちはわかる。だって開発者本人なんでしょ。


例えば飲食業だって大衆的なものだったり、1品だけのメニューを作り続ける屋台とかなら調理サーブを1人でやったりする。

でも、少し規模がでかくなったりメニューが繊細だったりすれば調理する者とサーブする者に分業するのは当然だ。

まり、今までにない機能をつけたwebサービスを開発するというトンデモない複雑なことをやりながら、

一方で現在稼働中サービスアクセスを解析し、どのような層に届くのか予想し、どんな風に告知するのかを最適化して、

ベータ版というものを全く理解していない人にもよくよく承知していただけるようにチュートリアル説明がきを用意して……

なんてことを、1人でできるわけないのである

ひとりでやっているかは知らんが、あの文章をみる限りそうとしか思えない。少なくとも仲間内には開発者しかいないんじゃないか

きっと、『マシュマロ』をつくったときも初めはベータ版を少数のフォロワーかに試してもらって、「ここ動いてないよ!」「ああそこはまだできてない!ごめん!もうちょっとかかる〜」とかやりとりしながら作っていたんだろう。

そのノリで今回もできると思ったのかもしれないが、もう既にマシュマロはそんな規模のサービスじゃなかったのだ。


文面を見てると「最初からそんなに利用されるサービスなんてない」風の記述があるが、それはきっと……初期のマシュマロの開発のリズムイメージした話なんだと思う。投稿者馬鹿にしている、という批判もあったけど、そこは違うと思う。「個人で開発したサービスなんだから最初は知人くらいしか使わないのが普通!」みたいな。開発者は、己が運営しているサービスポテンシャルをみくびっていたんだな、、多分。もしそれ(β版を試用してもらいながら最適化)をやりたいのなら、本当にオフで会ったことあるレベルの知人限定でやるべきだったと思う。その範囲なら多少やらかしても「ごめんごめん!」で済むので。





もし今回の炎上マシュマロ運営懸念して、今後ちゃんとやっていきたいならば、

カスタマーサポート専門家を雇った方がいい。

web開発に技術必要なのと同じで、開発に詳しくない人に、きちんと誠意が伝わるように説明するのだって技術必要仕事だ。

正直あの文面は「運営からお客様への返答」として見られたら最低だと思う。

だが、開発者カスタマーサポート技術まで求めるのは酷な話だ。本当に。



今のまま、サポート開発者兼任していたら、いずれ本当にどちらかを蔑ろにするしかなくなって破綻する。

というか現時点でも無茶をしている自覚があるのではないか

大事機能を開発途中で「β版で試して貰えばいいや!」と公開したのも、「β版」に関する説明不足で混乱をきたしたのも、全て「今の人員じゃ間に合わないから」なんじゃないのか?



カスタマーサポートを雇え。切実に。

2022-01-11

自社サイトリニューアル案件がひどすぎて死ねる…

もう誰でもいいから聞いてレスもらいたい気分なので書く。

うちは某大手不動産デベロッパーのN。

3年ぐらい前から自社サイトリニューアルが盛大に始まった。

プロジェクトが始まる直前ぐらいになんか全体を取り仕切る市場なんちゃらとかって部署出張ってきた。

始まった途端今までやってくれたベンダーを切って、自社内でズブズブの超大手SIerのNなんとかにコンペもなしに単独発注

経営への言い分は「不具合が多いから」とかなんちゃら言ってたらしい。(これが後にブーメランになります

で、結局2サイトあって、リニューアル2021年の夏ごろ予定していたのが、一つは12月ひとつ2022年の春予定に遅れに遅れまくっている。

この間に部長からがん詰めされ、遅れたら「なぜ遅れる?」と言われ、残業したら「残業なんか何故する?」と詰められ、鬱って倒れる人まででる始末。

挙句の果てに現場には新しい仕組みが全く共有されないままで、12月リニューアル分が現場オープンされたら、それまで普通に使っている機能まで勝手に削られていた。

もうマジで市場なんちゃらのトップは何も分かっていなくて自分功名心だけで現場潰している。

ユーザ用の機能まで勝手に削っていて、お客さまに告知もしていないのに、サービス劣化している。

今のSIer、超絶大手の癖に、既存サイトコードDBも全部提供してもらっている癖に2年もやってて全く解析していなくて、未だに「これってどういう仕様ですか?」「今のベンダーさんに確認してもらいたいです」と逝ってくる始末。

コードをみて、おまいらが解析しろ、糞高い金払ってるんだから、とマジでいいそうになった)

こんな恥ずかしい状態でそれまでのベンダーさんに相談しても「仕事が終わるって言われてたから、今からヘルプを言われても、もう別案件に入れちゃってます・・・ごめんなさい」と言われる(そりゃそうだ)

更にヤヴァいのが、既存ベンダーさんは同じことをするのに1本ちょっとと言っていた金額が、某Nなんとかは既に片手で収まらないレベルになっている。

もうこれって部長利益相反か、袖の下もらってるんじゃないのか?と言いたい。

そして、12月リリースしたサイトバグボコボコでてきている・・・

今のベンダーさんが不具合が多いから変えたんじゃないですか?めっちゃ完璧ものが出来るんじゃなかったんですか?とマジで言ってやろうかと思った(言ったら首になるから言えない)

今のベンダーさん、適度に安価結構な無茶(どうしてもDB直接修正しなきゃいけないとか)もなんとかやってくれてたのに、今のNなんとかは100%やってくれないだろうし、運用回るのか・・・これ・・・

今のベンダーさんが全部が良い訳じゃなくて、たしか不具合もあったけど、半分はこっちが超無茶なスケジュールで言ってて、テストらしいテストをしてもらう時間余裕もなかったのもあるけど、上は全部彼らの責任とかって経営にいっているらしい。

機能劣化するし、サービスレベル劣化するし、社内では倒れる人間がいるし、上役は良いことは俺の手柄、悪いのは部下の責任、という大和田常務を地で行く人で、さら案件の内容が某み○ほ銀行状態になっていて、この部署からマジで離れたい。

だれか少しでもいいので慰めてくれ。

東京住宅価格について思うこと

東京都では平均年収596万円に対し、マンション平均価格は7989万円と13.4倍に上ります

このニュースに限らないが、東京住宅価格は上がっている。過去20年くらいのグラフを調べればずっと上がっている。

主な要因は

  1. 長い間の低金利
  2. 共働きによる世帯収入の増加
  3. 不動産投資の増加
  4. 建築業界の人口
  5. 輸入材料価格上昇

と言われる。


個人的邪推していることを書かせてもらう。

  1. 人口減による分の住宅ローン総額減少を補填しようとしているのではないか住宅ローン会社側の都合に、高く売りたい不動産業界の都合が合わさったのではないか
  2. 買う人が居るから価格を上げるのは市場原理として当然というが、他の消費財と違い、収入を見て価格を決めることができる特殊性がある。
  3. 国の住宅ローンに対する補助金を前提に、不動産価格を決めてないか?(住宅ローン以外の名目補助金でもいい。子育て世帯への補助金とか)
  4. ダブルインカム世帯収入が増えたか住宅価格が上がったのではなく、逆ではないか。どちらかというとダブルインカム前提で価格を決めているのではないか
  5. 「物が売れなくなった」というのは住宅ローン返済の負担からではないか。そのくせ居住面積は小さく、物はおけない。
  6. 長期的には少子化になれば、住宅ローン会社不動産も困るが、短期的には、生まれから働き始めるまで時間差があり、住宅ローン返済への負担増で少子化が進もうが関係ない。(少子化からって政府批判こそされ、金融不動産業界は批判されない)
  7. 少子化でも世帯数が増えたというデータ業界にとって魅力的。
  8. 売れない分を、価格補填しているのではないか
  9. 本業で儲からない分を、不動産業で埋め合わせする所が多く、潰せないし、上がり続けるという予測を守らないといけない。
  10. アメリカだと新築不具合が多く、メンテをすることで中古市場価格は上がるが、日本は鍵を渡したら1000万単位で下がる。逆に言えば1000万新築は上乗せできる。



「35年ローン組んでも、補助金投資に回して早期返済する」とか、

価格上昇する所を渡り歩いていけばよく、波に乗れないやつが悪い」とか、

うまく世渡りしている事例はあるだろうが、世の中そういうやつばかりじゃない。

借金しすぎという話もこの間話題になっていたが、審査機関があり、そこがプロなんだから、無理を通してないのだったら審査で落とすべきだろう。


一般的工業製品だと、大量生産できるよう工場を建て効率化して生産性を上げれば価格は下落するが、不動産はそうではない。

もちろん現場での施工が入るという特殊性はあるが、下落するどころか上昇しすぎだろう。

上物ではなく土地価格だという意見もあるだろうが、それにしてもだ。


日本競争力の減少が、住宅に起因しているような気がしてならない。

住宅が狭すぎ物が置けない、住宅ローンが高すぎる、ローンを早く返済しないといけないので消費している場合ではない。景気低迷。

共働きでないとローンが返せない。少子化

政府補助金だそうにも住宅周りに全部吸い取られる。(補助金名目が直接的に住宅ローンでなくても間接的に)

景気も良くならない。

2022-01-10

anond:20220110030252

子供リスキー投資だよ

健康面で不具合持ったらそれだけで親は苦しむ

そうでなくとも20年弱は世間知らずで育つんだし最後は親のことなんてどうでもよくなって巣立つんから親にとってメリットってあんまりない

そういうリスクを背負うから社会がそれを支えるし何より独り立ちさせてしまえば後は全部本人の責任だよ

から斜に構える理由がない

社会を良くすることが子供にとっていいことなんだから

社会に貢献してきちんと幼いときに手放さなければ別になんとでもなる

投資としてはリターンないかもだけどその次がある

死ぬ間際に孫の顔みれればそれでプラスかもね

2022-01-09

anond:20220109171602

今後詳しく調査されて真相が違いましたってなる可能性はあるけど、少なくとも今の所は前日の担当者ミスシステム不具合って報道されてんじゃん。

まり自業自得ではないし、ニュースサイトひとつ開けば確認できるその情報を見ずに右手首なくなった飼育員を叩けちゃう人が山いるってことよ。怖くない?

2022-01-08

コロナの始めの頃にアホみたいに消毒ばかりするんじゃねえよ!って怒ってたイタリア医者がいたと思うんだけど

曰く、人は自然的に手や物からウィルスみたいなもの日常にとりこんで

それで抗体をつくることで健康を維持してるんだ、みたいな理論

なんでもかんでも消毒すると最終的にはひ弱になってしまうという解釈をしてたんだけど、

手洗い消毒マスク着用が普及してる現在、やっぱり何か見えない不具合は起きてるのかなあ?

2022-01-05

anond:20220105145054

心臓不具合があったら走れなくてもしょうがないし、アレルギーがあったら物食えなくてもしょうがないのに、脳に不具合があっても許されないのかわいそう

え、アレルギー好き嫌いだってはい・・・

anond:20220105191221

不整脈可能性あり。心臓不具合は命に関わるので医療機関で診てもらうことを強くおすすめします。

<辞めるまで日記

自分コミュ障

責任を負いたくないので正社員はやめ、派遣

・ほぼ女性、○○関係大工場勤務

仕事は出来ない、不器用

社会保険に入りたい  

 

  

 

仕事始め。 

朝礼にて

機械不具合の件を自分が感じていた事を

話していた。

 

作業検品だった。

長田(チョコプラ長田そっくり)は

いい人だがテンパってくるとヒス声、

上から目線こちらもイラッとしてくる。

まだ最初から言い方キツい人の方が受容できる。

残業長田と他メンバー悪口に華を咲かせてると推測。

明日、広まってるな。

評価低かろうが

嫌われようが

人間関係ギクシャクしようが

 

自分目的お金だ』

 

人間関係重要視していないか

メンタルは病まない。

無理に馴染もうとするから疲れる。

寂しい時もあるが嫌われてる方が気楽だ。

The コミュ障


 

 

2022-01-03

ミラーリングバックアップではない

京都大学でも意外とITの深いところまでは掘り下げないのね

スーパーコンピュータシステムファイル消失のお詫び

2021年12月28日火曜日掲載

京都大学学術情報メディアセンター

センター岡部 寿男

2021年12月14日 17時32分 から 2021年12月16日 12時43分にかけて,スーパーコンピュータシステムストレージバックアップするプログラム(日本ヒューレット・パッカード合同会社製)の不具合により,スーパーコンピュータシステムの大容量ストレージ(/LARGE0) の一部データ意図せず削除する事故が発生しました.

皆さまに大変なご迷惑をおかけすることになり,深くお詫び申し上げます.

今後,再びこのような事態の生じることのないよう再発防止に取り組む所存ですので,ご理解いただきますよう,どうぞよろしくお願いいたします.

ファイル消失の影響範囲

対象ファイルシステム:/LARGE0

ファイル削除期間:2021年12月14日 17時32分 ~ 2021年12月16日 12時43分

消失対象ファイル:2021年12月3日 17時32分以降,更新がなかったファイル

消失ファイル容量:約 77TB

消失ファイル数:約 3400万ファイル

・影響グループ数:14グループ (うち,4グループバックアップによる復元不可)

障害情報:【スパコンストレージデータ消失について

http://www.iimc.kyoto-u.ac.jp/ja/whatsnew/trouble/detail/211216056978.html

ファイル消失の原因

スーパーコンピュータシステムの納入会社である日本ヒューレット・パッカード合同会社によるバックアッププログラム機能改修において,不用意なプログラム修正とその適用手順に問題があったことで,本来不要になった過去バックアップログファイルを削除する処理が,/LARGE0 ディレクトリ配下ファイル群を削除してしまう処理として誤動作しました.

日本ヒューレット・パッカード合同会社から提出された報告書掲載します.

Lustreファイルシステムファイル消失について (日本ヒューレット・パッカード合同会社)

今後の取り組み

現在バックアップ処理を停止しておりますが,プログラム問題改善し,確実に再発しない対策をした上で1月末までにはバックアップを再開する予定です.

ファイル消失後にバックアップが実行されてしまった領域ファイル復元ができない状況となったこから,将来的にはこれまでのミラーリングによるバックアップだけでなく,1世代分の増分バックアップを残す等の機能強化を検討いたします.機能面だけでなく,再発防止に向けた運用管理についても改善に取り組みます.

一方で,機器故障災害等によるファイル消失可能性も含めて完全な対策は困難であるため,利用者の皆様におかれましても,重要ファイルについては別システムへのバックアップをお願い致します.

2022-01-01

anond:20220101102027

その通りです。

そうしたら何に不具合が起こるのか、という視点から考えるべき。

そうすると、少なくともトイレ風呂は「肉体的性別」で使用を分けるべきとなる気がするんだが。

2021-12-31

みずほ銀行で一時不具合人為的ミス

一人で手作業で切り替えとか

この会社マジ終わってるな

ここに口座持ってる奴は相当間抜け

https://news.yahoo.co.jp/articles/55e2e521edc786cbcef93ed36d341cc0f24a1dec

anond:20211231112736

VDI 導入、コロナ禍におけるビデオ会議課題改善

そして中長期の PC 環境の構想へ

リクルートにおける VDI の導入、運用コロナ対応、そして今後の ICT 環境を紹介する連載。

今回は、VDI 導入を振り返り、中長期の PC 環境の構想をお伝えする。

石光直樹,リクルート(2021 年 05 月 24 日)

23 →目次に戻る

 “ ネットワーク状況によっては使えないシーンがある点 ” は、VDI なら避けられない問題です。特に外出中は、ス

マートフォンによるテザリングで VDI に接続する際に、エリアや移動状況によっては通信環境が安定せず、通信

切断されたり、通信速度が遅くなったりするなど、VDI がスムーズ動作しないシーンがありました。この課題

対しては、スマートフォンテザリング容量の観点なども含めて検討し、対処してきましたが、完全には解決でき

ませんでした。そこで、VDI では業務遂行がどうしても困難なユーザー限定し、さらに高セキュリティ業務以外

での利用において通常の PCFAT PC)を配布するようにしました。

もう一つの課題ビデオ会議実施時の不具合 ” については、もともと VDI とビデオ会議親和性は良くない点

が前提にありますビデオ会議場合クラウドサービスを使うことが多いと思いますが、通常の PC なら、クラ

ウドサービスPC 上のビデオ会議ソフトウェアが直接つながり、ユーザーは快適にビデオ会議ができます。一方、

VDI の場合クラウドサービスと VDI 上のビデオ会議ソフトウェアがまず接続され、その後 VDI から VDI 専用端

末(シンクライアント端末)に音声と動画転送される形になります。音声も動画もいわば二重でデータ転送

れる仕組みなので、劣化してしまうのは避けられません。具体的には、音声が途切れ途切れになったり、動画

カクカクしてスムーズ動作しなかったりすることになります

また、システム管理観点でもデメリットがあります。通常の PC では、ビデオ会議ソフトウェア機能クラウ

サービスとのネットワーク接続状況をチェックしてくれて、最適に通信する仕組みなのに対し、VDI ではそのよう

機能は使えません。ビデオ会議ソフトウェアにその機能が搭載されていても、VDI から VDI 専用端末に通信

る段階でそれらの機能無効化されてしまうのです。その結果、VDI 上でのビデオ会議は通常よりも多くの通信

量が発生してしまい、外出時などテザリングの容量を圧迫することになっていました。

しかし、最近ではビデオ会議のこうした課題回避策として、クラウドサービス各社が VDI 用のソフトウェア

リリースしてくれるようになってきました。VDI 用のビデオ会議ソフトウェアを VDI にインストールして、一部のソ

フトウェアコンポーネントを VDI 専用端末にもインストールします。そうすることで、VDI と VDI 専用端末が協調

してビデオ会議端末として動作し、クラウドサービスと VDI 専用端末とが直接つながる構成になり、従来に比べる

と音声や動画劣化が大幅に避けられるようになってきています

24 →目次に戻る

中長期の PC 環境を構想する――“ 中長期 ” という新たな観点の導入

 以上をまとめると、いまの VDI 環境では当初想定したメリットは得られたものの、ネットワークビデオ会議

おいてそれぞれの課題がありますネットワーク課題は、一部ユーザーFAT PC を配布することで、ビデオ

議の課題については VDI 用のビデオ会議ソフトウェアインストールすることで解決できます。いまの VDI 環境

評価するマトリクスを作って検討してみると、VDI 用のビデオ会議ソフトウェアがうまく動作すれば、VDI 環境

をそのまま継続するのが妥当なように見えました。とはいえ、そのような “ カイゼン策 ” を施しながら、VDI をい

まの形のまま続けるべきなのでしょうか。そして、そのような思考プロセスに本当に問題はないのでしょうか――。

われわれは検討時に、新たな視点を導入することにしました。それは “ 中長期 ” 視点です。2015 年においては、

3 つの課題という、“ いま、ここ ” における課題に対する解決策として VDI を採用したものの、今後長きにわたっ

会社を支えていくPC 環境を構想するに当たり、それだけでは不十分ではないかと考えました。リクルートは創

から 60 年以上がたちました。今後も長きにわたりカスタマークライアントの皆さんのためにより良いサービ

スを提供し続けることになるでしょう。それには短期的な視点だけではなく、中長期でのあるべき PC 環境を描い

て、それに向かっていまどうすべきかを考えなければならないと思ったのです。

そのためには、まず働き方が将来的にどうなるかを想定しなければなりません。次期 PC 環境検討していたの

コロナ禍前でしたが、ゆくゆくは「完全に場所を選ばない働き方」になるだろうと予想していました。キーワード

で示すならば、「Anytime/Anywhere/Securely/Work Digitally」という表現になるでしょうか。そのような働き方

を実現する PC 環境については、既にいわれて久しいですが、クラウド中心の方向性は変わらないでしょう。加えて、

今後は多種多様デバイスが出現すると想定しました。いまは PC や VDI が中心であり、補助的にスマートフォン

使われているというのがビジネスにおける PC 環境の実情だと考えます。では、今後はどうなるのか――。

スマートフォン中心になるという見方もありますが、学校では情報教育が進みノート型の端末が支給されており、

家庭においてはスマートスピーカーが広まりAR/VR拡張現実仮想現実)もゲームなどを中心に広がってき

ています。また、企業では製造業などで AR/VR が使われる事例も出てきており、IoT デバイスもいろいろなユー

スケースが生まれてきました。

そう考えると、ユーザーが使う端末は、どれかの端末に収束していくのではなく、2in1 あるいはクラムシェル

などの PCスマートフォンタブレットAR/VR デバイススマートスピーカーIoT などいろいろなデバイス

使いこなしていく世界になるのではないかと考えます業務のさまざまな場面で、いろいろなデバイスの中から

適なものを選び、さまざまなクラウドサービスを使いこなし業務をしているイメージです。それらを使うことで、場

所を選ばず、どこにいても対面同様のコラボレーションができるでしょう。さらには、AI人工知能技術などを

活用しながらユーザー業務支援するなどして、高い生産性を生み出すことができる環境になっていくのではな

いか、と予測します。

25 →目次に戻る

中長期視点で考え、いま行動する――「クラウドマルチデバイス環境」へ

われわれは、このような環境を「クラウドマルチデバイス環境」と呼ぶことにしました。中長期的には「クラ

ウドマルチデバイス環境」になるとして、VDI の EOSL 契機に対応しなければならないわれわれの次の PC

境はどのように整えたらいいのでしょうか。

 大事なのは、「中長期視点で考え、いま行動する」ことです。中長期視点だけを考えれば、一気に「クラウド

マルチデバイス環境」にすべきでしょう。ところが、われわれの環境内にはまだレガシーシステムが残っており、一

気にクラウドだけを利用する業務形態に変えるのは困難でした。また、検討した結果、現時点では VDI に勝るよ

うなセキュリティ確保の仕組みは見当たりませんでした。そのため、情報資産の囲い込みができるという点で、高

セキュリティ環境に対しては継続して VDI を活用することにしました。

セキュアな環境以外の用途においては、“ いま ” のことだけを考えれば、ビデオ会議の部分のみを改善して VDI

環境のまま、次期 PC 環境を作る方向もあり得ました。しかし、それでは今後の PC 環境が VDI に固定化されて

しまうことになります。VDI 環境をいままでと同様にオンプレミスで作るには、初期に大きな設備投資必要とな

り、また一度構築してしまうと使い捨てるわけにもいかず、それをしばらく運用し続ける必要があります。今後い

ろいろなクラウドサービスデバイスが出現すると、活用したいと思う方も多いでしょうが、既に VDI を使ってい

場合、VDI の代わりに別のものをすぐに使うということはなかなかできません。そういう意味で、PC 環境が固

定化されてしまうことになるのです。

 中長期の環境に一気に切り替える方針でもなければ、現在のことだけ考える方針でもなく、「中長期視点で考え、

いま行動する」方針検討した結果、次期 PC 環境は「クラウドマルチデバイス環境」を目指すための第一

位置付け、「VDI と FAT PCマルチ環境」を構築することに決定しました。先述した通り、レガシーシステム

存在し VDI 以上に情報の囲い込みができるソリューションがない中で、VDI から離れ、一気に中長期的な将来

像を目指すのは困難です。とはいえ「将来像に向けた環境をいま作るべき」と考え、VDI と FAT業務特性に応

じてユーザーに配布するマルチ環境刷新することにしました。つまり、高セキュリティ業務ユーザー向けにはセ

キュリティを確保した「セキュア VDI」、それ以外の一般ユーザー向けには FAT PC を配布することにしたのです。

将来的にはマルチデバイスといっても、いまだ PC がメインなので、まずは PC を配布し、その上で今後 AR/VR

デバイスといった他のデバイス検討していきたいと考えています

なお、VDI 環境としてはもう一つ、機能更新がない固定的な OS必要とするレガシーアプリ向けの環境も VDI

で用意することにしました。用途限定されていることから、社内では「特定用途 VDI」と呼んでいます

26 →目次に戻る

VDI 用のビデオ会議ソフトウェア導入による 2 つの課題

 以上をまとめますと、働き方は中長期的に「完全に場所を選ばない働き方」へと変わり、それに応じて PC

境は「クラウドマルチデバイス環境」になっていくでしょう。われわれも VDI の EOSL のタイミングで変わって

いかなければならず、将来に向けた第一歩として、次期 PC 環境は「VDI と FAT PCマルチ環境」を実現する

ことにした、ということになります

なお、コロナ禍において、われわれは現在の VDI 環境下でビデオ会議改善を試みました。先述した VDI 用

ビデオ会議ソフトウェアの導入を検討し、一部導入したのです。その結果、ビデオ会議の音声と動画品質

極めて改善されることになったものの、2 つの課題が新たに見つかったのです。

1 つ目は、普通ビデオ会議ソフトウェアと VDI 用のソフトウェアとの間に機能差があった点です。この課題

今後解消されるかもしれませんが、われわれが導入した段階では VDI 用のソフトウェア機能面で劣っていました。

2 つ目は、導入/管理コストです。1 つのビデオ会議システムしか使っていない場合問題いかもしれません

が、複数使っていたり、今後新しいシステムの導入を考えようとしたりすると、ソフトウェアの導入、管理に都度

工数がかかってしまうという難点が明らかになりました。

 以上 2 点については、いま検討されている方のご参考になれば幸いです。次回は、リクルートがいままさに取り

組んでいる「VDI と FAT PCマルチ環境」についてお話します。

2021-12-30

寝たい時間なのに行動したくなる不具合

ただでさえ超夜型家庭の育ちな上最近食事夕方と日付がかわってから摂っている

お陰様で睡眠リズムももガバガバ、起床が夕方って事も増えたし最悪

そのせいなのか深夜位にやたら何か活動したくなる、というか逆説的に色々束縛が無く自由活動出来るのが深夜の時間しかない

でもそういう時間に起きているのも良くないと思っている、というか出来れば眠りたい

でも結局ダラダラと起きて今もこんな時間だ、最悪!今日殆ど何も出来なかったぞ!

睡眠リズムさないとなぁ‥‥けど中々スッキリ起きられない、故に二度寝も長くなる

とりあえずもう寝ます

2021-12-27

都内なのにパートナー回線が消費されてるー

なんだろ?着信不具合関係かな

2021-12-25

<辞めるまで日記

自分コミュ障

責任を負いたくないので正社員はやめ、派遣

・ほぼ女性、○○関係大工場勤務

仕事は出来ない、不器用

社会保険に入りたい

    

  

12/24で 17日目 

 

 

自分から申し出る前に外され

勤続年数長い方が作業をした。

 

何個か作った製品に破損が発覚し

全部破棄となった。 

  

ベテラン

「怖いー、検品したくないー」

と保身から騒いでいた。

新人でもベテランでも見落とす時は見落とすだよ、検品問題じゃねーんだよ。

はよエンジニア呼んで機械を直せよ。

今週頭に機械に大きな不具合発覚してんだよ。

頻繁に調子悪く機械ストップ、再開。

素人が調整しても所詮応急処置程度、

それこそ

生産ロスじゃねーか。

現に半日以上仕事ならんかったぞ。

と、内心思った。 

 

コミュ障仕事低能力ゆえに

みんなからじわじわと嫌われあからさまな態度に

変わってきた。 

 

使ってください。と自分が用意したら

無視され自ら同じ道具持ってきたよ。

辛いけど、無理する自分も疲れる。

ぞんざいに扱われてもいいよ。

そういうキャラ徹底してみようかな。

と、自分も考えが変化してきた。  

  

 

十人十色、色々な人がいると痛感。

でも、ここの人達特別かな。

2021-12-23

ワクチン接種証明アプリ旧姓対応について

ワクチン接種証明アプリ旧姓対応していない件について、なんか論点のずれた擁護拡散されてるみたいなので書く

https://togetter.com/li/1819901

擁護派としてはアジャイル開発のようなものを持ち出して「完璧でない状態リリースして何が悪いのか」という主張を展開しているが、ここで我々が批判したいのはアプリが不完全な状態リリースされていることではなくて、約束を守らない政府である

選択夫婦別姓制度の導入を頑なに拒み「旧姓通称使用の拡大を進めていく」というよくわからないエクスキューズで常にお茶を濁し続けてきた政府が、ワクチン接種証明アプリというまさに政府公式アプリにおいてちゃっかりと旧姓使用弊害を導入してしまっている矛盾

まり我々がすべきことはアプリバグ修正ではなく強制的夫婦同姓制度解体であり、この件でアプリ不具合エンジニアリング観点から擁護してしまうことは、選択夫婦別姓制度をめぐる政府矛盾を追認することになってしまう。

擁護派もエンジニアとして言いたいことはわかるが、もう少し大きな視野を持って議論できないものかと思う。

ログイン ユーザー登録
ようこそ ゲスト さん