code finished - how can i make sure it doesnt crash or break?

<p>Hey everybody.</p> <p>I&#39;m finished with my project and now I have to make sure I can get 99% uptime, I&#39;m wondering what steps I should do next to try to secure and make my app as stable as possible? Any pointers or checklists of what to do? It&#39;s a mmo web server/game written in Go</p> <p>The caveats are I dont have any panic handlers/defers in my code currently, is panic handling important? If my app crashed I can bet I&#39;m not gonna be there to fix it or get the stack trace, what should I do?</p> <p>Sorry if this is so vague, any uptime tips or security tips or things like &#34;use go race detector first&#34; are acceptable. I&#39;m just trying to get my code from finished to production ready</p> <hr/>**评论：**<br/><br/>peterbourgon: <pre><p>Using the race detector is a good idea. Anything it finds is a definite problem and needs to be fixed — it has no false positives. Also look at <a href="https://github.com/kisielk/errcheck">errcheck</a>. Your code should definitely pass <code>go vet</code>, and probably pass <a href="https://github.com/golang/lint">golint</a>, too.</p> <p>Beyond that it&#39;s difficult to give advice. Can you link to the source?</p></pre>mc_hammerd: <pre><p>Good advice. Thanks. Can you tell me why errcheck is useful? I&#39;m not getting it from the index.md</p></pre>peterbourgon: <pre><p>In Go it&#39;s possible to ignore errors, especially if they&#39;re the only return from a function you trust, like <code>fmt.Printf</code>, or <code>filehandle.Close</code>. errcheck tells you about them.</p></pre>23inhouse: <pre><p>You might be able to use defer and recover.</p> <pre><code>defer func() { if err := recover(); err != nil { foobar() } }() </code></pre></pre>mc_hammerd: <pre><p>Do i have to try to create these panics and then make sure my app works after it recovers? how can i know my app isnt gonna run for 2 days deleting/shredding/not saving data after it recovers, before i discover it :X</p> <p>anyone done this before? had a bug that occured only have recover()?</p></pre>peterbourgon: <pre><p>In general you shouldn&#39;t do this, as unless you know exactly what you&#39;re recovering from and how to recover from it, you&#39;re just putting your program in an unknown state — better to crash and know what happened.</p></pre>calebdoxsey: <pre><p>For the server its important to add monitoring. At a basic level you can use an outside service (like pingdom, but there are many others) to monitor an HTTP endpoint, but you probably want a deeper level of monitoring. A lot of companies use nagios, but a more modern approach would be hashicorp&#39;s consul.</p> <p>It&#39;s also useful to keep track of metrics. The monitoring should catch total failures (HTTP is unreachable, a machine is dead, etc..) but it probably won&#39;t tell you much about reduced performance (and even if it did it almost never tells you <em>why</em> something is behaving badly) I&#39;ve only ever used graphite, but there are a lot of other products out there too. Just build a bunch of graphs to chart usage, request times, etc... and leave a window open all the time. You&#39;d be surprised how many issues you can spot before a user ever realizes something is wrong.</p> <p>The game client is trickier. At some point it will have issues (at a minimum someone&#39;s machine will do something strange which you didn&#39;t account for), so having a path for users to submit bugs would be good. If you can add something to the program to make that easier that may be worthwhile (some sort of &#34;your program crashed, would you like to send an error report)... but the truth is most games don&#39;t really do that. They just have a forum setup somewhere.</p> <p>Outside of that it really comes down to testing. You can harden your software by throwing realistic usage at it. That can be hard for something brand new (because you probably don&#39;t have any real idea of what the traffic will look like) but you could also try pushing it until it breaks. See how many connections a server can handle, at what point the database starts to slow down, etc...</p> <p>I think though for almost all software it&#39;s also a matter of flexibility going forward. You&#39;re not building something that&#39;s perfect, but if you keep an eye on it and have a good foundation, you should be able to address any issues that come up quickly.</p> <p>MMOs are notoriously bad at launch, so I&#39;d guess you will have a fair bit of headroom when it comes to what users will put up with.</p></pre>mc_hammerd: <pre><p>thanks for this i will check out those software.</p> <p>i wrote a server monitor so i should have that covered, i have logs and analytics. im not catching client side errors yet so i will have to add that (Good suggestion), and ill probably setup a forum to get bug reports.</p> <p>i guess its just a MO not a mmo :D </p> <p>thanks for the help</p></pre>