The way I typically see this implemented is via a Hierarchy custom setting.

Create a custom setting of type hierarchy called Trigger_Disabled__c. Then you can create Account_Disabled__c, Contact_Disabled__c etc fields on it for the particular sobject instances you need to disable.

Why a hierarchy setting? You could use list custom settings as well, but if you wanted to disable workflows or validation rules as well, you can reference hierarchy custom settings in formulas.

The way I typically see this implemented is via a custom setting.

Create a custom setting of type hierarchy called Trigger_Disabled__c. Then you can create Account_Disabled__c, Contact_Disabled__c etc fields on it for the particular sobject instances you need to disable.

Why a hierarchy setting? You could use list custom settings as well, but if you wanted to disable workflows or validation rules as well, you can reference hierarchy custom settings in formulas.

Additionally, custom hierarchy settings will allow you to enable / disable the trigger for different users based on the organization hierarchy, etc.

In your trigger you would reference the trigger enablement check similar to below:

trigger AccountTrigger on Account(before insert){
    Trigger_Disabled__c triggerDisabled = triggerSettings.getInstance();
    if(triggerDisabled == null || !trigger.Disabled){
       //call your method or logic here
    }
}