ランサムウェア

ディスクを独自フォーマットをしてそのソフトウェアを経由しないと読めなくしている。

ＯＳからの権限奪取と、ファイル・ディスクを暗号化し読めなくする2つの機能に分けて説明していきたい。

カウントダウン画面が表示されたら、ＰＣの電源を切る　すぐに　電源ボタン長押しでよいと思う。

別のＯＳで起動し、データディスクとしてマウントしてデータをコピーする。
これでデータの退避はできるのではないか、感染したＯＳで起動させてしまうと、データの暗号化処理がすすんでしまうからだ。データ退避を保証できません。運がよければ程度です。

後継

エンジニアとして自分と同じ失敗は繰り返さないようにと、ドキュメントを作成したり、後輩に行動や言葉で継承したりする。プロジェクトとしてもある意味ISOの品質管理もその趣旨が含まれていると思う。

徒弟制度ではないので、さまざまなモチベーションや立場、生活の中の仕事の位置づけが異なる継承者につたえていく。どちらかがでなく、セットで力をあわせていくことが大事である。経験則ばかりでなく新しい視点の大切だと思う。

そんななか、同じ失敗が繰り返されていく、品質がいつまでたっても向上しない。そもそもそんな想いもない人がシステム開発にたずさわっている。

この行動に対する、費用はだれがどのプロジェクトで負担するのか？の問いのように。

わるいことばかりではない、新しい発想や新機能をつかって、効率を上げる場合もある。

WINDOWS OSの拡張子の非表示弊害

WINDOWS　OSには、拡張子を非表示にする機能がある。ソフトウェアやバッチファイルの作成には、開発時と同様の設定が必要だ、この機能が開発時と異なると扱うデータファイルの拡張子が 二重拡張子となりファイル名の文字化けにつながる。

ライセンス管理

サーバ更改ごとにアプリケーションを新規購入していませんか

ハードウェアは、更改してもソフトウェアはバージョンアップして利用できる場合がある、社内で利用しているアプリケーションを管理すれば、値段にもよるが、アップデートして利用すればまとまった節約をすることができる。保守契約は継続して結ぶべきだが比較検討してみてはいかがでしょうか？

バックアップ・DR環境との同期方法でライセンスが節約できる。

マニュアルは読まれない

 どんなに丁寧なマニュアルであっても利用されなければ意味がない。昨今の流れとしてマニュアルを読まないユーザーが多い。

iPhoneであっても印刷物のマニュアルはない。確かに多くの機能やを搭載したスマホの機能のすみずみまで印刷物のマニュアルに記載したら膨大な量になってしまう。

そこでオンラインマニュアルの登場となる。端末ローカルに配置されたものと、インターネット上に配置されたものがある。メリットデメリットはそれぞれある。だから、結構使い込んでいるのにこんな機能あったのと気付く場合もある。

システム構築のなかで、製品に対する

サポートデスクに問い合わせを実施すると、「マニュアルのXXXに記載があります」と丁寧な回答のあとに付け加えられることが多い。一般ユーザというより技術者用ではあるが。

オンラインマニュアルも記載レベルもわからないし、そもそも全部目を通すわけではないので、オンラインまゆあるにおいてはインデックスが大切になると思う。サポートに他人に聞く前に自分でどう調べたか。ここで質問の質もレベルも変わってくる。あらぬ誤解・誤認を呼ぶ場合もあるが。人が答えてくれるのは安心感がある。ゆえにサポートの人が勘違いしないような適切な質問のしかたも大切だ。

大事なことは全部マンガが教えてくれた

マンガの作品の場面を、短く切り取り人生の示唆的教訓を教えて、または紹介してくれている。やるじゃんマンガ。やるじゃんリクナビ。と感動した。リクナビNEXTが紹介してくれている。検索してみて。

なにもないときに見直そう

運用方式において
無駄な冗長化をしている。
無意味な作業（処理）を継承しているため変更が困難。
無駄なデータをバックアップをしている。
バックアップと災害対策対応とあわせたため
同期対象・バックアップ対象に
目的外のデータが同期対象に含まれネットワークに負荷がかかっている。
見直してみよう。
テープが・ディスクが・バックアップ時間が節約できる。

たまたま

システムのエラーで、ものすごい少ない確率でしか起こらないようなことが、現実には発生する。
　良心的な場合は、開発中に発生し、そうでない場合は、運用中に発生する。
よりによっての条件がいくつも重なりピンポイントでそこを突いてくる。不思議だ。

外に出てみる

私のパソコンは、部屋の奥にある、明かりとりの窓はあるが外の景色も見えない窓だ。
場所によって、発想や仕事の効率、集中力がかわる。これもモバイルテクノロジーが、小型化が進んだおかげだ。家ならではの安らぎと、外に出て感じられる緊張感や刺激。上手に使い分けていきたい。
テレワークが始まり、ここで作業をするしかない。小さな部屋だまたいえだ。お仕置き部屋みたいだ。家の掃除の邪魔でもある。テレビ会議もここでやるしかない。バックの背景も気になるところだ。喫茶店での作業などできるわけない。会議の内容がもれてしまうし、意外と声もおおきくなってしまう。それにコロナのため不要不急の外出禁止でもあるし、おいしい飲み物でも準備してみようと計画している。
あと運動不足にも注意だ、出勤分の運動がなくなってしまう。体重が記録更新してしまう。着る服のサイズもきになる。

ネットワーク名前解決の順序

ネットワーク上のコンピュータの名前解決には、複数の要素がある。この優先順位を理解していないと、正しいネットワークのサーバ間の通信ができない。要素がと優先順位について確認してみたい。

1番目
 DNS リゾルバーキャッシュを確認して、指定された名前に対応するレコードがキャッシュされている場合、そのアドレスを返す。

2番目
 HOSTSファイルを参照し、指定された名前に対応するレコードが登録されている場合そのアドレスを返す。

3番目
登録されている DNSサーバーがある場合は問い合わせを行い、受領したアドレスを返す。

4番目（WINDOWS）
上記処理で名前解決に成功しない場合は、NetBIOS 名前解決を行う。

2番目と3番目については、よく知られているかと思う。1番目のキャッシュについては忘れがちで動作が想定外となるケースがある。ご注意を。

RFC

RFC（Request for Commentsの略）インターネット等（プロトコル）の仕様を決めているところ、サイト、自由に参加できる（英語のサイトで日本語訳も出まわっている）。参加したり意見を述べるにはそれなりの理解度が必要ですね。歴史と未来が読み解けるといいですね。こういうところで定義されているんだと知ることや、仕様を理解し開発をする上では大切なサイトだと思います。
私も、FAXの仕様を調査した経験があります。印刷データそのものは受信できているのですが、データ内の終了コードを受取ることができず、完了せず再送されてしまい何枚も同じ文書が出力されてしまいました。

中にはこんなジョークもまじってるいのです。まことしやかに記載されています。

 RFC2324 ハイパーテキストコーヒーポット制御プロトコル(HTCPCP/1.0)