2018-12-11 Непродуктовые Опции В Конфигурации
Различия
Здесь показаны различия между двумя версиями данной страницы.
Следующая версия | Предыдущая версия | ||
правила_разработки:как_не_надо_делать:2018-12-11_непродуктовые_опции_в_конфигурации [11.12.2018 11:11] nikolay_carbonsoft1 создано |
правила_разработки:как_не_надо_делать:2018-12-11_непродуктовые_опции_в_конфигурации [20.05.2019 15:18] (текущий) |
||
---|---|---|---|
Строка 1: | Строка 1: | ||
+ | **Постановка задачи:** у клиента понадобилось повысить размеры таблицы conntrack и таблицы маршрутов в ядре для повышения производительности. При этом, текущие значения уже регулируются скриптами. | ||
+ | **Решение:** В продукт добавляются 2 опции с размерами: | ||
+ | <code bash> | ||
+ | firewall['ipv4.route.max_size.widget']='inputbox "Максимальный размер кеша IPv4 маршрутов" ""' | ||
+ | firewall['ipv4.route.max_size']='2621440' | ||
+ | firewall['netfilter.nf_conntrack_max.widget']='inputbox "Максимальное количество conntrack" ""' | ||
+ | firewall['netfilter.nf_conntrack_max']='1048576' | ||
+ | </code> | ||
+ | В скриптах константа меняется на значение параметра в конфиге. | ||
+ | |||
+ | **Другой пример: ** тест доступности DNS-серверов не успевал получить ответ за timeout по-умолчанию. Решили ввести опцию корректировки: | ||
+ | <code bash> | ||
+ | app['dns_timeout']='1' | ||
+ | </code> | ||
+ | |||
+ | **Ошибка:** Опции продукта предназначены для решения проблем клиентов, а не для экспериментов с настройками параметров и тонкого тюнинга. Какой параметр указать - решает наша система сама, причем несколько параметров в комплексе, рассинхронизация параметров может привести к нестабильности системы. Клиент не должен выбирать системные параметры - это зона ответственности продукта. А у клиента должна быть большая кнопка "Сделать хорошо", причем желательно автоматическая. | ||
+ | |||
+ | **Другая, менее очевидная проблема:** гибкая конфигурация на клиенте, либо использование кастомных hook-файлов со спец.настройками на клиентах приводит к тому, что экспертиза, которую получают инженеры тех. поддержки или разработчики, отлаживая клиенсткую систему, **остаются у клиента и не попадают в продукт**, не делают продукт лучше, не развивают его. Даже внутри компании из-за этого данная, уже решенная проблема, может решаться несколько раз разными людьми, из-за того, что экспертиза недостаточно хорошо распространилась. | ||
+ | |||
+ | **Как нужно:** Допустим: разработчик нашел проблему, поняв что у некоторых клиентов нужно повышать параметры буфера из-за высокой сетевой нагрузки. Тогда: если изменения подходят всем клиентам - добавляем изменения без опций, если некоторым - делаем 1 опцию типа boolean, которую называем одноименно с проблемой, которую она решает (желательно в продуктовом формате): "Включить оптимизацию для большого количества трафика (более 10 гигабит/сек)". Если опция еще не отлажена, т.е. не собрано достаточно примеров что эта опция хорошо работает на разных конфигурациях, можно указать что опция экспериментальная. Если это спец.конфигурация для нагруженных инсталляций, потом к ней могут привязываться другие изменения. | ||
+ | |||
+ | **Что нужно было сделать с DNS: ** нужно сделать опцию "DNS сервера могут долго отвечать", если нам нужно это контроллировать или просто поднять таймаут в самом скрипте без опции. | ||
+ | |||
+ | ~~OWNERAPPROVE~~ /*Не удаляйте эту строку и ниже!*/ | ||
+ | |||
+ | {(rater>id=1|name=Прочитал_правила_разработки:2018-12-11_непродуктовые_опции_в_конфигурации|type=vote|trace=user|tracedetails=1)} | ||
+ | |||