201902¶

google on board¶

google のBorgのOSS版なのか...
app engine は裏でborgが動いているけどGoogle のベンダロックイン的な感じがする．
なのでk8s engineを提供していて，それは汎用性が高くなっている．
- borgにできてk8sにできないことがまだあるので，その辺りとのトレードオフ．
- 将来的にはk8sがborg(app engine)に追いついてくるだろうと考えられる．

paramikoでsshのときにエラー出る¶

  /usr/local/lib/python3.6/site-packages/paramiko/kex_ecdh_nist.py:39: CryptographyDeprecationWarning: encode_point has been deprecated on EllipticCurvePublicNumbers and will be removed in a future version. Please use EllipticCurvePublicKey.public_bytes to obtain both compressed and uncompressed point encoding.
    m.add_string(self.Q_C.public_numbers().encode_point())
  /usr/local/lib/python3.6/site-packages/paramiko/kex_ecdh_nist.py:96: CryptographyDeprecationWarning: Support for unsafe construction of public numbers from encoded data will be removed in a future version. Please use EllipticCurvePublicKey.from_encoded_point
    self.curve, Q_S_bytes
  /usr/local/lib/python3.6/site-packages/paramiko/kex_ecdh_nist.py:111: CryptographyDeprecationWarning: encode_point has been deprecated on EllipticCurvePublicNumbers and will be removed in a future version. Please use EllipticCurvePublicKey.public_bytes to obtain both compressed and uncompressed point encoding.
    hm.add_string(self.Q_C.public_numbers().encode_point())

CryptographyDeprecationWarnings with cryptography 2.5 release Âˇ Issue #1369 Âˇ paramiko/paramiko Âˇ GitHub
pip install cryptography==2.4.2

requirements.txt¶

脳死する方法

  $ pip freeze > requirements.txt
  $ pip install -r requirements.txt

Pythonのコードと同様#以降はコメント
==,>, >=, <, <=などでバージョンを指定できる．省略すると最新版が入る．
,で区切るとAND指定
ex.) 1.0以上かつ2.0以下のバージョンを指定するとき package >= 1.0, <=2.0

docker x netns¶

NICの命名が¶

ensXX とかethXXとか

/etc/default/grubを修正
たとえば

  $ sudo sed -i 's/^GRUB_CMDLINE_LINUX=""$/GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"/g' /etc/default/grub 
  $ sudo update-grub
  $ sudo reboot

eve¶

How To Add Cisco IOU/IOL To Eve-ng - NetworkHunt

SRE # 2019-03-04 15:08:40 YudaiHashimoto¶

@enakai00 氏
Middlewares in Google
- 分散ファイルシステム: Google File system / Colossus
- 分散No SQL: Bigtable
- 分散RDB: Spanner
- 分散ロックマネージャ: Chubby
- 分散ロードバランサー: Maglev
- ストリームデータ処理: FlumeJava
- Others: オブジェクトストア，ログングサービス，分散ビルドシステム
- !: 多くがGCP上で提供されている．
Google のSRE
- Googleにおいて，ソフトウェア開発やが望むシステム運用業務を考えられて作られた組織がSREチーム
- 安定的にサービスを提供することを目的とした場合，ソフトウェア開発者であれば何をするか．→ソフトウェア開発者に運用(安定的なサービス運用)までさせたい(そのほうがbetterだよね)
- システム運用だけでなく，安定運用するために必要なソフトウェア開発を合わせて行うチームが誕生．→SREチーム
- !: サービス運用をがんばってやるんじゃなくて，安定運用，安定的な開発フローが実現できるような仕組みを作ることが大切．当たり前だけどなかなかできない．
- システム運用の'目的'を明確に定義
SREチームの活動内容
- システム運用(On Call, Postmortems，アドミ処理，etc...)を50%'以下'でやる．
- のこりの50%以上でソフトウェア開発を含む（自分の強みが発揮できる）システム安定化に関わるプロジェクト活動に充てる．
  - モチベも上がる．
- 50%ルール．（実際に守れている）
- Burnout（燃え尽き症候群）を防止．→必要な人材を燃え尽きさせねい（会社を辞めさせるわけにはいかない．損失だから．）．合理的．
- 自動化とかを自分で行える．そのようなソフトウェア開発をするモチベーションが上がる．
- 開発チームに対して，運用の手間がかからずに安定稼働するシステムを'そもそも'開発するモチベーションを上げる．
  - !: そういうことを考えてつくる（これは非常に大切だと思う）．
- SREチームは50%ルールを脅かすようなシステムを開発チームからその運用を引き受けない，もしくは運用要員の提供を受ける権利を有する．
- 共通インフラ，ミドルウェアや，重要度の高いアプリケーションは専任のSREチームが運用．
  - 小規模で重要度が低いもの，もしくSREチームが必要で無いほど安定しているアプリケーションはSREチームは運用しない．
  - SREチームは自分たちが運用するアプリケーションをなくすことが究極のゴール
- courseraのSREトレーニングコースってのがあるよ！
SLO(Service Level Objective)の認識
- 何を持って安定とするか．安定の定義．
- SLOが満たされている == 安定しているという共通認識をもつ．
- 客観的，数値的に決める．
  - 99%に対して Success Statusを返す．
  - Status Success の99%は200ms以内に応答を返す
  - しかし数値を考えるのは簡単では無い．
  - 全員が納得できるSLOの数値を議論して改善し続ける．
  - SLOを高くしすぎると，SLOが守れなくなった瞬間にSREチームから開発チームに突き返され，開発チームは現在の開発を全てやめてdebugということになりかねないので適切に設定する．
- エラーバジェット
  - 1 - SLO = Error Buget
  - エラーの許容値
  - 期間を定めて計算する
  - Error BugetがなくなるとSLOが満たされていないと判断する．
  - Error Bugetの消費状況をモニタリングをして，これがなくなりそうな場合は抜本的な対策を生じる．
SREチームがデザインレビューを提供する．
- 開発チームからの設計をレビュー．
- デプロイ，運用時にどんな問題が起こるかを知っているのは開発者ではなくSREチーム．そのチームから意見を乞う仕組み．
- 設計もある程度共通化，標準化が実現できるため，運用が用意になる．
- 安定化の必要な開発ポリシーを開発チームにスキルトランスファ
その他
- Toil(労力のかかる作業)の削減
  - Toilを徹底的になくす．
  - 大規模なシステムを小規模チームで運用するためには不可欠．
  - Burnoutの帽子
  - 運用作業/障害対応の自動化を促進．
- もしエラーが起きてもユーザ影響の'インパクトを下げる'という形で対処するなどで対処する．
  - 検索であれば，一部サービスに障害が出ても，検索が全くできなくなるということはせずに，実は検索の精度が下がっている（がユーザはそれに気づかない）など．
  - 全体のSLOは高いけれども，個々のSLOは低くするなど．
  - 止まっても困らないように作れ（わざとサービスを止めてもよいように．chubbyの話）
- postmortem の書き方は決まっている．google車内でトレーニングもある．
- 要害対応のプロセス
  - オンコール担当者のIncident Commander(障害対応責任者)となり，Communicatinons Lead(報告責任者)とOps Lead(実作業担当者)を任命
  - 問題解決を最優先して，他人に頼ることを本人のスキル不足とは認識しないことを徹底．
    - !: たしかに他の人に聞くと，自分のスキル不足を自分で認めるという考えになりがち．
    - 人に頼ることが普通/betterであるという見方をする．そういう文化を徹底する．
    - 誰に頼めば解決するかというのがわかるというもの大変重要なスキルである．
- Postmortem(障害報告書)
  - 重大障害の解決後に，発生要因，対応時の反省点，改善策などを文書化．
  - !: Google Docsにかく．1人1doc
  - 個人を非難する内容は絶対に書かない．(個人のミスを誘発するシステムを設計したのがわるい．)
  - 改善策の実施はSREチームのプロジェクトつとして実施
  - 社内のすべてのエンジニアに内容を公開．
    - 障害対応により得られた知見をすべてのエンジニアと共有．
    - 障害対応の実地訓練にも活用．
  - 知っていること，やったこと，見たもの，なにもかも全てをdumpする．
  - !: たしかにこれは非常に重要．情報を余すことなくdumpする．知っていることはなんでも．小さいことでも．
Google 社内では社員間の情報共有が非常にゆるい．たくさんの人と共有．
The 12 Factor App
source/resourceのコードでの構成管理
単体テストのケオ↑雨滴結合
モダンなエンジニアリングの地道な実践