Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
(いたみん)プロジェクトでの運用改善について
Search
akatsukinewgrad
August 02, 2021
Programming
0
1.4k
(いたみん)プロジェクトでの運用改善について
akatsukinewgrad
August 02, 2021
Tweet
Share
More Decks by akatsukinewgrad
See All by akatsukinewgrad
2023/1/25_QAテスター meet up!
akatsukinewgrad
0
110
成果発表資料.pdf
akatsukinewgrad
0
1.9k
広大なフィールドを気持ちよく駆け抜けるための技術.pdf
akatsukinewgrad
0
470
正規表現とReDoS.pdf
akatsukinewgrad
0
470
Unityで大量のオブジェクト_を吹き飛ばしたい.pdf
akatsukinewgrad
0
490
新卒2年目が思う1年目の学び.pdf
akatsukinewgrad
0
440
障害訓練の取り組みについて.pdf
akatsukinewgrad
0
560
7分でわかるアカツキゲームス
akatsukinewgrad
0
480
Bitcoinだけでスマートコントラクト.pdf
akatsukinewgrad
1
750
Other Decks in Programming
See All in Programming
PipeCDの歩き方
kuro_kurorrr
3
130
Remix on Hono on Cloudflare Workers
yusukebe
1
380
romajip: 日本の住所CSVデータを活用した英語住所変換ライブラリを作った話
sangunkang
0
2.2k
React CompilerとFine Grained Reactivityと宣言的UIのこれから / The next chapter of declarative UI
ssssota
7
2.6k
[FlutterKaigi2024] Effective Form 〜Flutterによる複雑なフォーム開発の実践〜
chocoyama
0
3.9k
Figma Dev Modeで変わる!Flutterの開発体験
watanave
0
3.7k
競技プログラミングで 基礎体力を身につけよう / You can get basic skills through competitive programming
mdstoy
0
130
デザインパターンで理解するLLMエージェントの作り方 / How to develop an LLM agent using agentic design patterns
rkaga
11
2.2k
よくできたテンプレート言語として TypeScript + JSX を利用する試み / Using TypeScript + JSX outside of Web Frontend #TSKaigiKansai
izumin5210
7
2.7k
flutterkaigi_2024.pdf
kyoheig3
0
340
Jakarta EE meets AI
ivargrimstad
0
1.2k
ペアーズにおけるAmazon Bedrockを⽤いた障害対応⽀援 ⽣成AIツールの導⼊事例 @ 20241115配信AWSウェビナー登壇
fukubaka0825
6
2.3k
Featured
See All Featured
Faster Mobile Websites
deanohume
305
30k
KATA
mclloyd
29
14k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.3k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Typedesign – Prime Four
hannesfritz
40
2.4k
Scaling GitHub
holman
458
140k
Building an army of robots
kneath
302
43k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Embracing the Ebb and Flow
colly
84
4.5k
Transcript
プロジェクトの 運用改善について Akatsuki Geek Live Vol.1
名前:伊丹琢人(いたみ たくと) あだ名:いたみん • 役職 ◦ 19卒クライアントエンジニア ◦ 八月のシンデレラナイン
urakataチーム所属 • 趣味 ◦ fpsやアクションのゲームをする ◦ Vtuberの放送を見たり 最近便利家電を揃えててなるべく楽をしようとしてます 自己紹介
urakataチームとは 新機能などユーザーに価値を提供するチームではなく 運用メンバーに対して価値を提供するチームになります。 現在:クライアント1人、サーバー2人の体制 ハチナイの運用メンバーは主に以下の職種の方がいます • プランナー • 検証
• デザイナー
なぜ運用メンバーに価値を提供するのか?
なぜ運用メンバーに価値を提供するのか? • 手作業による工数の増大 • ヒューマンエラーによる不具合 ユーザーへの還元、最終的にプロジェクトの利益に繋がる 解決
どうやって問題を見つけるか? • まずはヒアリングしてみる → そもそも解決できる問題として認識していないこともあるため 色々と引き出す必要がある。 • 運用改善のslackチャンネルを作成・要望シートに記載を促す →
改善の文化形成、ふとした要望も受け入れるようにして 問題の浮上をしやすく。
• 改善仕様のヒアリングを行う。 → その仕様よりも良いことはないか? 実装工数と工数や不具合の削減量でやるやらないを決定していく • ものによって、コンフルを整備したり → 改善したのに使われないままになったり、引き継ぎができないのを防止
問題解決へ
運用改善 1例の紹介 マスターデータの移行を自動化
ハチナイではマスターデータはスプレで管理されていて 各環境毎にシートがあり、環境によってシートを結合して使います マスターデータの移行作業: 概要 develop sandnext sandbox feature
develop sandbox develop feature sandbox feature sandnext sandbox sandnext sandbox sandbox ※これは一部です
今回はここでの改善 マスターデータの移行作業: 概要 develop sandnext sandbox feature develop
sandbox develop feature sandbox feature sandnext sandbox sandnext sandbox sandbox
sandnext: 本番で使うが、まだ出さないデータで出す日付もバラバラ sandbox : 本番で使うデータでここにあるデータを本番やstagingといった環境に反映 します マスターデータの移行作業: 概要 sandnext sandbox
sandnext sandbox sandnext sandbox sandbox
マスターデータの移行作業: 概要 本番で出すにはsandnextからsandboxへ移動させる必要があり 今まで手作業で移動をさせていた。 また全部ではなく基本次回で出るデータのみ sandnext sandbox 手作業
マスターデータの移行作業: 現状の問題把握 • データ不備の発生 • シートが大量にあるため複数人が最大1時間かかる。しかも増えていく • 当時手作業が当たり前という意識の状態だった
不具合発生・必要工数ともに大きい問題 解決しないとマズイ!
マスターデータの移行作業: 解決への実装と仕様 • 言語はプロジェクトに合わせてrubyを選択 • 実行はjenkins上。パラメータに移動対象の日付を指定してポチるだけ! • 実行結果はslack上に通知
マスターデータの移行作業: 移動の判定 • マスターデータの一番右の列に”デプロイ”を追加して日付を指定 • デプロイ列までを移動対象に • 入れ込むデータは元々判断できるようでデプロイ列はそこに含めない 実際にデータ化されるシート
操作するシート 参照
マスターデータの移行作業: 実装の注意 • 100秒あたり100リクエストの制限 → 制限が来たら待機・リトライ処理を追加 • シートごとにリクエストすると重いのでまとめて処理をする → batch_update_valuesやbatch_get_spreadsheet_valuesを使用
運用していくとシートが増えて制限に引っかかるのも sheets apiの制限についてこちらから https://developers.google.com/sheets/api/reference/limits
マスターデータの移行作業: 作業と結果 • デプロイ日を入れて実行 • 実行結果をslackへ 各マスターで移動ができたら成功アイコン表示
マスターデータの移行作業: 改善効果 • 工数 → 2~4人 x 30 ~ 60分
x 2 ~ 3回デプロイ/1ヶ月 = 最大12時間くらい削減 → + 作業は非同期なので本来の作業に集中可能 通知も平均6分ほどで来る • 不具合 → 処理がデータによっては不具合が発生することがある。 行を手動で追加しないといけなかったりとか・・・ とはいえ手作業でほぼ毎回発生していた不具合は削減
• プロジェクトにspineを導入し、anima2dからspineへの移行 • photoshopスクリプトで必要なspineアトラスを出力するもの • iosのテクスチャ圧縮の更新 PVTRC -> ASTC •
実機内デバッグ機能で検証コストの低減 • github actionでチェッカーを入れたり 他運用改善で行ったものの例
• 運用を続けるプロジェクトは運用を改善していくことも重要 運用し続け肥大化したプロジェクトはどこか負担になっている箇所があり 本来注力すべき業務の時間が減って結果として利益に影響が発生します。 機能実装の攻めと改善の守りで攻守兼ね備えたプロジェクトへ • 改善できるのか?を言いやすい環境へ 負担になって辛いけどしょうがない・・から改善できるかも?に繋げるため チームでコミュニケーションを取ってよりよいチームビルディングへ
まとめ
• iosのPVTRC -> ASTCへの移行 元々PVTRCは縦横ともにサイズが2の累乗だけ対応なので いくつか圧縮されていなかった。-> アセットバンドルの サイズ増大
ASTCに関してはそこが緩和されており置き換えてサイズ削減へ ただしiphone6以降が対応 • anima2dからspineへの移行はアニメーション周りの方からの要望 業界的にspineのほうが扱える方が多くやりやすいというのと、anima2dはもうサポート的にどうなの? という感じだったので移行をしています。 spineはcanvas用とmesh renderer用の2パターンあるので相性が良かった appendix
• 実機内デバッグではSRDebugger経由でアクセスするものが多いです 例えばローディング演出の確認デバッグとか 試合開始のVSが出てるところの確認デバッグとかのキャラ表示チェックとか • photoshopスクリプトはspineのスケルトンデータ1つに対して
キャラのテクスチャを切り替えて表示する形を取っているので 同じ配置になるようphotoshopから自動で配置して出力する機能を作成 appendix