For filling out 202503 FOC GA Operational Readiness Review, I wanted a place to assemble an outline based on a couple of different brainstorming attemtp.
<aside>
What are the risks we want leadership to be aware of “eyes wide open” so they are making an informed decision about us launching?
</aside>
| Risk | Severity If It Happens | Expected Likelihood | How would we know if it happens? | How Mitigating Currently? | How to improve for the future? |
|---|---|---|---|---|---|
| Two copies aren’t actually stored | Low severity to drop one copy, but we need to be alerted depending on which copy drops | ~20% | |||
| SP walkaway | high severity if that SP is endorsed, low severity if just approved | ||||
| Critical bug found in Filecoin Pay | |||||
| Non-upgradeable bug found in PDPVerifier or FWSS | |||||
| Slow time to react to react to an SP that significantly degrages in performance | |||||
| SPs are on their best behavior for the dealbot but not for paid clients | For pieces with iIPFS indexing | ||||
| • check that the ipfsRootCID is in IPNI. | |||||
| • Randomly retrieve some of these IPFS Root CIDs and their children | |||||
| IPNI write path failing | New pieces will not be retrievable with standard IPFS tooling because | ||||
| IPNI read path failing | |||||
| Various conventions aren’t documented |
<aside>
What are the qualities of our system that we think customers should rely on? For each of these, we should “pull the thread” to see how we’re ensuring that guarantee is happening.
</aside>
| Guarantee | How do we guarantee it? | |
|---|---|---|
| Two copies stored by default | ||
| Stored data is retrievable | ||
| There are enough SPs to handle user-requested data | ||
| Filecoin Pay funds are secure |
<aside>
Should likely related to the User Guarantees. This is a useful question for helping us boil down what is most important.
</aside>