There is no doubt that Drush is a magical tool in the Drupal community. Two very useful tools in the Drush "Swiss Army Knife" include
drush sql-sync and
drush core-rsync. These tools allow copying databases and files between Drupal instances.
If you need to have access to run Drush commands on a production server or via a Drush alias for a production server, policy.drush.inc can help prevent some devastating mistakes. Accidentally overwriting production databases and files can impact you and your clients negatively. The Github gist below shows how the built-in Drush policy functionality can prevent
core-rsync from running against any Drupal instance that has a destination with
prod in the name. This works for Drush aliases too.
policy.drush.inc file in
~/.drush on the machine you use to run Drush. The code in the gist above prevents operations like
drush sql-sync @dev @prod and
drush core-rync @dev:%files @prod:%files
Drush's policy.drush.inc allows for a few other functions for validation and alters. It is worth reviewing the options and implementing changes to prevent accidents that can be prevented.
While the above works well, the best way to prevent accidental production issues due to developer mistakes is to have a policy implementing separation of duties. In this sort of policy, developers would not have access to production servers. Devops engineers would handle deploys manually or manage the automation that handles deployments.
Thank you to all of those who have worked so hard to make Drush a fantastic tool that I depend on daily.