Production Mode

I already mentioned it in my introduction, so let's start with this one: Magento 2 has three modes: A Default Mode that you should never ever use, a Developer Mode that should be used when modifying the shop and the Production Mode ... (you guessed it) for production. The production site should always be in Production Mode, to guarantee best performance and best behaviour. If you put your Magento 2 live in Developer Mode, because of reasons, you should fix whatever needs to be fixed and switch to Production Mode quickly. If a developer tells you that the Developer Mode is needed for the production site, slap that developer in the face. The only reason why a production site is running in any other mode than Production Mode is insufficient knowledge.

PHP 7

The minimum requirement of Magento 2 might still be PHP 5.6, but with Magento 2.2 this is going to change. And actually, PHP 7 is the only active stable PHP version out there. And Magento 2.2 will no longer support PHP 5.6. It is a no-brainer.

Enable caching

All of the caches should ideally be enabled in the live site, except perhaps the Page Cache. The Block Cache should be turned on. In Magento 1.X I sometimes kept this off, because there was (depending on situations) no big performance benefit. In Magento 2, most blocks are cachable by default (cacheable=true) and the Block Cache simply enables this caching. If a block should not be cached, you could mark this block with cacheable=false. However, keep reading.

Furthermore, no block should be marked as cacheable=false. If a block is made non-cacheable, the entire page where that blocks lives is made non-cacheable as well, so that the Full Page Cache does not work. We want the Full Page Cache to work, so every block should be marked cacheable=true. If a developer says a block can't be created as a cacheable block, because of session-specific data, than that developer should dive into the procedure of Private Content (documented by Magento, including KnockoutJS and UiComponent behaviour). It might be hard. But not having Full Page Cache available will cause the shop owner to loose money (because more loading time equals less revenue).

Because of the above, you should attempt to enable the Full Page Cache as well. And if this works, you can optionally replace the native Page Cache with Varnish. Hurray!

All the other caches should be enabled. No discussion.

Redis

File caching can be slow. Use Redis instead.

Document root should be pub/

The document root - as it is configured in the Virtual Host definition of the webserver - should be pointed to pub/. Using the Magento 2 root itself is dangerous and opens up for lots of security risks.

Deployment process

To copy changes from a development environment to a live site, there should be a deployment procedure. Either this means that you have post-it note that determines how you copy changes from one environment to another, or it is actually a scripted procedure (Capistrano, and there are many alternatives). Not having a deployment procedure ready means that you are not ready for production yet. Make sure to test the procedure intensively, so that you know sure how to upgrade and how to roll-back.

Latest versions

Magento 2 has had its fair share of security issues already. Make sure that you go live with a secure version, preferably the latest version. Upgrading Magento 2 should be a breeze thanks to composer.

Testing

If you are worried about things falling apart after an upgrade, I would not say there is nothing to worry about. However, not upgrading because of this fear, is a wrong choice. Instead, you should focus on upgrading and to guarantee that there are no new bugs after this upgrade, you should test things. You can setup your own manual tests (clicking through pages), automate browser actions (Selenium) or write unit tests (PHPUnit). If you are new to testing, don't try to test everything at once - that would be overwhelming. But try to create tests first for those areas where it would hurt most: Make sure 1 developer spends 1 day on learning Codeception with Selenium, so that integration tests for add-to-cart actions, product pages and the checkout are created. Next, once the tests are there, run them automatically after every commit, when going live or through a cronjob.

There might be more points, but hopefully this gives already a good jumpstart on what to go live with. If you have more tips and tricks, feel free to share!