Sound problem workaround что это
Workaround
Обходной приём, или Workaround — обходное решение проблемы, выявленной в системе (в простонародии «костыль»). Обходной приём обычно является временным исправлением, подразумевающим, что требуется подлинное решение проблемы. Очень часто обходные приёмы так же креативны, как истинные решения, и требуют нестандартного мышления.
Обычно они рассматриваются как неустойчивые варианты, не отвечающие в полной мере будущим требованиям, выходящим за рамки изначального дизайна системы. При реализации обходных приёмов важно пометить изменение так, чтобы в будущем разработать подходящее решение.
Обходные решения применяются в разных областях человеческой деятельности, не только в программировании.
Содержание
Причины применения обходных решений
Примеры широко известных обходных решений
В программировании
В технике
В медицине
Примечания
Полезное
Смотреть что такое «Workaround» в других словарях:
workaround — (n.) by 1987, from WORK (Cf. work) (v.) + AROUND (Cf. around) … Etymology dictionary
Workaround — A workaround is a bypass of a recognized problem in a system. A workaround is typically a temporary fix that implies that a genuine solution to the problem is needed. Frequently workarounds are as creative as true solutions, involving outside the … Wikipedia
Workaround — Unter einem Workaround (englisch für: [um etwas] herum arbeiten bzw. in etwa Abhilfe) versteht man die Umgehung eines bekannten Problems innerhalb eines technischen Systems durch eine Hilfskonstruktion. Es ist eine provisorische Lösung, die die… … Deutsch Wikipedia
Workaround — Un workaround ou work around (avec un trait d’union), anglicisme signifiant littéralement « travail autour », parfois traduit en solution de rechange ou de contournement[1], est, notamment en informatique, le contournement d’un bug ou… … Wikipédia en Français
Workaround — Notbehelf; Behelfslösung; Umgehungslösung * * * Workaround [dt. »ein Problem angehen«], das Überarbeiten von fehlerhafter Hard oder Software, bei der aber der Fehler nicht beseitigt, sondern nur ein Lösungsweg angegeben wird, den Fehler zu… … Universal-Lexikon
workaround — An ingenious, undocumented way to solve a problem. ► “One workaround is to print a business letter on plain stock and then photocopy it onto the letterhead.” (MacWorld, Dec. 1994, p.135) … American business jargon
workaround — noun /ˈwɜː(ɹ)k.əɹaʊnd/ a) A means of overcoming some obstacle, especially an obstacle consisting of laws, regulations, or constraints. b) A procedure or a temporary fix that bypasses a problem and allows the user to continue working until a… … Wiktionary
workaround — n. manner of bypassing a problem caused by a bug without correcting the bug itself (Computers) … English contemporary dictionary
workaround — noun Computing a method for overcoming a problem or limitation in a program or system … English new terms dictionary
workaround — /ˈwɜkəraʊnd/ (say werkuhrownd) noun Chiefly Computers Colloquial a temporary means of bypassing or avoiding a particular problem without addressing its cause … Australian-English dictionary
Sound problem workaround stalker anomaly что это
Так как мы все используем разные графические настройки, разработчики позаботились об удобстве игрока. С самого начала нас встречает лаунчер, где мы уже можем выбрать подходящие установки графики для повышения производства внутри игры. Так же мы вольны настроить и саму игру «под себя». От уровня экономики и наград до системы маскировки, выпадения лута, аспекты влияющие на сложность вроде радиации.
В модификации добротно и грамотно реализована система крафта. От простой установки модификаций. До полной сборки с 0ля новых предметов, само собой из компонентов. Замена повреждённых запчастей и многое другое.
Промежуточные итоги
Само собой пока еще рано делать выводы, все таки до прохождения модификации еще очень далеко. Тем не менее я уже могу сказать, что лично мне мод понравился, я планирую проходить его дальше и писать вам об этом статьи. Если же вам интересно посмотреть, как происходило все, о чем здесь написано, можете посмотреть видео с моего Ютуб канала.
Начало игры
Сложность игры и экономики я поставил среднюю, так как боялся, что на высокой противники будут наглым образом прерывать мою жизнь, выстрелами через пол карты, а ценники не позволят купить даже бинт, но, забегая на перед, могу сказать, что опасения оказались беспочвенными.
Закончив с косметикой, мы попадаем в деревню новичков. Я сразу же побежал проверять близлежащие дома на предмет полезных находок и не прогадал, так как в некоторых сундуках и ящиках действительно что-то лежало, а не как это бывает в некоторых модах.
Помимо этого Борис (как я назвал главного героя в честь не малоизвестного киноперсонажа) отправился набирать все задания, которые могут предложить нам местные обитатели. Квесты сделаны крайне разумно и не отправят вас сразу же через 4 локации от старта. Есть даже миссии по сопровождению, когда ты ведешь из пункта А в пункт Б одного или группу сталкеров. Выполнять их кстати очень выгодно, так как пока мы не оказались в точке назначения, спутники будут вовсю помогать нам в перестрелках, иногда давая возможность только собирать хабар с поверженных противников.
Искусственный интеллект
ИИ, как мне кажется, одна из самых больших проблем модов. Очень сложно найти баланс между интересными противниками и НПС, которые убивают с одного выстрела из другой локации. Не буду врать, в Аномали тоже есть свои недостатки.
Противники особо не тупят и не рассматривают стены, но вот огонь ведут из самых неожиданных мест. Идете себе, никого не трогаете, вдруг стрельба. Оказывается вас заметил бандит с ПМ-ом сквозь кусты за 100 метров. Хорошо хоть, что их меткость хромает, потому как чтобы понять, откуда вообще летят пули, нередко уходит несколько минут. Союзники тоже умом не блещут, спокойно могут встать в проходе, не давая пройти, погнаться за собакой, которая давно уже убежала, или просто так расстрелять деревянный ящик посреди лагеря. В общем развлекаются, как могут.
Sound problem workaround stalker anomaly что это
stack trace:
что это?
Помогите
Задание ответы вылет на диологах со стрелком
Бойтесь уязвимостей, воркэраунды приносящих. Часть 1: FragmentSmack/SegmentSmack
Всем привет! Меня зовут Дмитрий Самсонов, я работаю ведущим системным администратором в «Одноклассниках». У нас более 7 тыс. физических серверов, 11 тыс. контейнеров в нашем облаке и 200 приложений, которые в различной конфигурации формируют 700 различных кластеров. Подавляющее большинство серверов работают под управлением CentOS 7.
14 августа 2018 г. была опубликована информация об уязвимости FragmentSmack
(CVE-2018-5391) и SegmentSmack (CVE-2018-5390). Это уязвимости с сетевым вектором атаки и достаточно высокой оценкой (7.5), которая грозит отказом в обслуживании (DoS) из-за исчерпания ресурсов (CPU). Фикс в ядре для FragmentSmack на тот момент предложен не был, более того, он вышел значительно позже публикации информации об уязвимости. Для устранения SegmentSmack предлагалось обновить ядро. Сам пакет с обновлением был выпущен в тот же день, оставалось только установить его.
Нет, мы совсем не против обновления ядра! Однако есть нюансы…
Как мы обновляем ядро на проде
Тем не менее работы всё равно много, и она может занимать несколько недель, а при возникновении каких-либо проблем с новой версией — до нескольких месяцев. Злоумышленники это прекрасно понимают, поэтому нужен план «Б».
FragmentSmack/SegmentSmack. Workaround
К счастью, для некоторых уязвимостей такой план «Б» существует, и называется он Workaround. Чаще всего это изменение настроек ядра/приложений, которые позволяют минимизировать возможный эффект или полностью исключить эксплуатацию уязвимостей.
В случае с FragmentSmack/SegmentSmack предлагался такой Workaround:
«Можно изменить дефолтные значения 4MB и 3MB в net.ipv4.ipfrag_high_thresh и net.ipv4.ipfrag_low_thresh (и их аналоги для ipv6 net.ipv6.ipfrag_high_thresh и net.ipv6.ipfrag_low_thresh) на 256 kB и 192 kB соответственно или ниже. Тесты показывают от небольшого до значительного падения использования CPU во время атаки в зависимости от оборудования, настроек и условий. Однако может быть некоторое влияние на производительность из-за ipfrag_high_thresh=262144 bytes, так как только два 64K-фрагмента могут одновременно уместиться в очереди на пересборку. Например, есть риск, что приложения, работающие с большими UDP-пакетами, поломаются».
Сами параметры в документации ядра описаны так:
На продакшен-сервисах больших UDP у нас нет. В LAN фрагментированный трафик отсутствует, в WAN есть, но не значительный. Ничто не предвещает — можно накатывать Workaround!
FragmentSmack/SegmentSmack. Первая кровь
Первая проблема, с которой мы столкнулись, заключалась в том, что облачные контейнеры порой применяли новые настройки лишь частично (только ipfrag_low_thresh), а иногда не применяли вообще — просто падали на старте. Стабильно воспроизвести проблему не удавалось (вручную все настройки применялись без каких-либо сложностей). Понять, почему падает контейнер на старте, тоже не так-то просто: никаких ошибок не обнаружено. Одно было известно точно: откат настроек решает проблему с падением контейнеров.
Почему недостаточно применить Sysctl на хосте? Контейнер живёт в своём выделенном сетевом Namespace, поэтому по крайней мере часть сетевых Sysctl-параметров в контейнере может отличаться от хоста.
Как именно применяются настройки Sysctl в контейнере? Так как контейнеры у нас непривилегированные, изменить любую настройку Sysctl, зайдя в сам контейнер, не получится — просто не хватит прав. Для запуска контейнеров наше облако на тот момент использовало Docker (сейчас уже Podman). Докеру через API передавались параметры нового контейнера, в том числе нужные настройки Sysctl.
В ходе перебора версий выяснилось, что API Docker не отдавало все ошибки (по крайней мере, в версии 1.10). При попытке запустить контейнер через “docker run” мы, наконец-то, увидели хоть что-то:
write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container : [9] System error: could not synchronise with container process.
Значение параметра не валидное. Но почему? И почему оно не валидное только иногда? Выяснилось, что Docker не гарантирует порядок применения параметров Sysctl (последняя проверенная версия — 1.13.1), поэтому иногда ipfrag_high_thresh пытался выставиться на 256K, когда ipfrag_low_thresh ещё был 3M, то есть верхняя граница была ниже, чем нижняя, что и приводило к ошибке.
На тот момент у нас уже использовался свой механизм доконфигуривания контейнера после старта (заморозка контейнера через cgroup freezer и выполнение команд в namespace контейнера через ip netns), и мы добавили в эту часть также прописывание Sysctl-параметров. Проблема была решена.
FragmentSmack/SegmentSmack. Первая кровь 2
Не успели мы разобраться с применением Workaround в облаке, как стали поступать первые редкие жалобы от пользователей. На тот момент прошло несколько недель с начала применения Workaround на первых серверах. Первичное расследование показало, что жалобы поступали на отдельные сервисы, и не на все серверы данных сервисов. Проблема вновь обрела крайне неопределённый характер.
В первую очередь мы, конечно, попробовали откатить настройки Sysctl, но это не дало никакого эффекта. Различные манипуляции с настройками сервера и приложения тоже не помогли. Помог reboot. Reboot для Linux столь же противоестественен, сколь он был нормальным условием для работы с Windows в былые дни. Тем не менее он помог, и мы списали всё на «глюк в ядре» при применении новых настроек в Sysctl. Как же это было легкомысленно…
Через три недели проблема повторилась. Конфигурация этих серверов была довольно простой: Nginx в режиме прокси/балансировщика. Трафика немного. Новая вводная: на клиентах с каждым днём увеличивается количество 504-х ошибок (Gateway Timeout). На графике показано число 504-х ошибок в день по этому сервису:
Все ошибки про один и тот же бекенд — про тот, который находится в облаке. График потребления памяти под фрагменты пакетов на этом бекенде выглядел следующим образом:
Это одно из самых ярких проявлений проблемы на графиках операционной системы. В облаке как раз в это же время была пофикшена другая сетевая проблема с настройками QoS (Traffic Control). На графике потребления памяти под фрагменты пакетов она выглядела точно так же:
Предположение было простым: если на графиках они выглядят одинаково, то и причина у них одинаковая. Тем более, что какие-либо проблемы с этим типом памяти случаются чрезвычайно редко.
qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1024 flows (1021 inactive, 0 throttled)
0 gc, 0 highprio, 0 throttled, 464545 flows_plimit
«464545 flows_plimit» — это и есть пакеты, дропнутые из-за превышения лимита очереди одного соединения, а «dropped 464545» — это сумма всех дропнутых пакетов этого шедулера. После увеличения длины очереди до 1 тыс. и рестарта контейнеров проблема перестала проявляться. Можно откинуться в кресле и выпить смузи.
FragmentSmack/SegmentSmack. Последняя кровь
Во-первых, спустя несколько месяцев после анонса уязвимостей в ядре, наконец, появился фикс для FragmentSmack (напомню, что вместе с анонсом в августе вышел фикс только для SegmentSmack), что дало шанс отказаться от Workaround, который доставил нам довольно много неприятностей. Часть серверов за это время мы уже успели перевести на новое ядро, и теперь надо было начинать с начала. Зачем мы обновляли ядро, не дожидаясь фикса FragmentSmack? Дело в том, что процесс защиты от этих уязвимостей совпал (и слился) с процессом обновления самого CentOS (что занимает ещё больше времени, чем обновление только ядра). К тому же SegmentSmack — более опасная уязвимость, а фикс для него появился сразу, так что смысл был в любом случае. Однако, просто обновить ядро на CentOS мы не могли, потому что уязвимость FragmentSmack, которая появилась во времена CentOS 7.5, была пофикшена только в версии 7.6, поэтому нам пришлось останавливать обновление до 7.5 и начинать всё заново с обновлением до 7.6. И так тоже бывает.
Во-вторых, к нам вернулись редкие жалобы пользователей на проблемы. Сейчас мы уже точно знаем, что все они связаны с аплоадом файлов от клиентов на некоторые наши серверы. Причём через эти серверы шло очень небольшое количество аплоадов от общей массы.
Как мы помним из рассказа выше, откат Sysctl не помогал. Помогал Reboot, но временно.
Подозрения с Sysctl не были сняты, но на этот раз требовалось собрать как можно больше информации. Также крайне не хватало возможности воспроизвести проблему с аплоадом на клиенте, чтобы более точечно изучить, что происходит.
Анализ всей доступной статистики и логов не приблизил нас к пониманию происходящего. Остро не хватало возможности воспроизвести проблему, чтобы «пощупать» конкретное соединение. Наконец, разработчикам на спецверсии приложения удалось добиться стабильного воспроизведения проблем на тестовом устройстве при подключении через Wi-Fi. Это стало прорывом в расследовании. Клиент подключался к Nginx, тот проксировал на бекенд, которым являлось наше приложение на Java.
Диалог при проблемах был такой (зафиксирован на стороне Nginx-прокси):
При этом сеть на этот сервер приходит в виде Vlan-теггированного трафика, которое тоже добавляет свои поля в пакеты:
А ещё этот трафик может фрагментироваться (тот самый небольшой процент входящего фрагментированного трафика, о котором мы говорили при оценке рисков от Workaround), что тоже меняет содержание хидеров:
Ещё раз: пакеты инкапсулированы Vlan-тегом, инкапсулированы туннелем, фрагментированы. Чтобы точнее понять, как это происходит, проследим маршрут пакета от клиента до Nginx-прокси.
Нет, таких пакетов на сервере не было. Таким образом, проблема должна быть раньше. Есть ли пакеты со снятым только Vlan-инкапсулированием?
0xx390x2xx — это IP-адрес клиента в hex-формате.
32:4 — адрес и длина поля, в котором записан SCR IP в Tunnel-пакете.
Есть ли фрагменты пакетов без снятого Vlan- и Tunnel-инкапсулирования?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Эта магия покажет нам все фрагменты, включая последний. Наверное, то же можно зафильтровать по IP, но я не пытался, поскольку таких пакетов не очень много, и в общем потоке легко нашлись нужные мне. Вот они:
Это два фрагмента одного пакета (одинаковый ID 53652) с фотографией (видно слово Exif в первом пакете). По причине того, что на этом уровне пакеты есть, а в склеенном виде в дампах — нет, то проблема явно со сборкой. Наконец-то этому есть документальное подтверждение!
Декодер пакетов не выявил никаких проблем, препятствующих сборке. Пробовал тут: hpd.gasmi.net. Сначала, при попытке туда что-то запихать, декодеру не нравится формат пакета. Оказалось, что там были какие-то лишние два октета между Srcmac и Ethertype (не относящиеся к информации о фрагментах). После их удаления декодер заработал. Однако никаких проблем он не показал.
Как ни крути, кроме тех самых Sysctl ничего больше не нашлось. Оставалось найти способ выявления проблемных серверов, чтобы понять масштаб и принять решение о дальнейших действиях. Достаточно быстро нашёлся нужный счётчик:
Он же есть в snmpd под OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).
«The number of failures detected by the IP re-assembly algorithm (for whatever reason: timed out, errors, etc.)».
Среди группы серверов, на которых изучалась проблема, на двух этот счётчик увеличивался быстрее, на двух — медленнее, а ещё на двух вообще не увеличивался. Сравнение динамики этого счётчика с динамикой HTTP-ошибок на Java-сервере выявило корреляцию. То есть счётчик можно было ставить на мониторинг.
Наличие надёжного индикатора проблем очень важно, чтобы можно было точно определить, помогает ли откат Sysctl, так как из предыдущего рассказа мы знаем, что по приложению это сразу понять нельзя. Данный индикатор позволил бы выявить все проблемные места в продакшене до того, как это обнаружат пользователи.
После отката Sysctl ошибки по мониторингу прекратились, таким образом причина проблем была доказана, как и то, что откат помогает.
Мы откатили настройки фрагментации на других серверах, где загорелся новый мониторинг, а где-то под фрагменты выделили даже больше памяти, чем было до этого по умолчанию (это была udp-статистика, частичная потеря которой не была заметна на общем фоне).
Самые главные вопросы
Почему у нас на L3-балансировщике фрагментируются пакеты? Большинство пакетов, которые прилетают от пользователей на балансировщики, — это SYN и ACK. Размеры этих пакетов небольшие. Но так как доля таких пакетов очень велика, то на их фоне мы не заметили наличие больших пакетов, которые стали фрагментироваться.
Причиной стал поломавшийся скрипт конфигурации advmss на серверах с Vlan-интерфейсами (серверов с тегированным трафиком на тот момент в продакшене было очень мало). Advmss позволяет донести до клиента информацию о том, что пакеты в нашу сторону должны быть меньшего размера, чтобы после приклеивания к ним заголовков туннеля их не пришлось фрагментировать.
Почему откат Sysctl не помогал, а ребут помогал? Откат Sysctl менял объём памяти, доступной для склеивания пакетов. При этом, судя по всему сам факт переполнения памяти под фрагменты приводил к торможению соединений, что приводило к тому, что фрагменты надолго задерживались в очереди. То есть процесс зацикливался.
Ребут обнулял память и всё приходило в порядок.
Можно ли было обойтись без Workaround? Да, но велик риск оставить пользователей без обслуживания в случае атаки. Конечно, применение Workaround в результате привело к возникновению различных проблем, включая торможение одного из сервисов у пользователей, но тем не менее мы считаем, что действия были оправданы.
Большое спасибо Андрею Тимофееву (atimofeyev) за помощь в проведении расследования, а также Алексею Кренёву (devicex) — за титанический труд по обновлению Centos и ядер на серверах. Процесс, который в данном случае несколько раз пришлось начинать с начала, из-за чего он затянулся на много месяцев.
Как на русский перевести workaround
так чтобы одним словом, и не «костыль», а допустимо для упоминания в деловой переписке.
Временное решение проблемы первым заработавшим способом :>
Кроме костыля нет аналогов в одно слово.
и не «костыль», а допустимо для упоминания в деловой переписке
Будь мужиком, начни употреблять «костыль», и, возможно, в ближайшем будущем это будет вполне допустимо.
решение, хак, околоработа, враппер, абстракция, переопределение, обход, обходник, переходник, заплатка, накладка, прокладка, способ, метод, затычка
«подпорка» ещё (подпереть)
Wiki говорит «обходное решение», так же «временное решение» и «костыль».
не «костыль», а допустимо для упоминания в деловой переписке
а что так с костылем? костыль он и есть костыль. вполне распространенное слово в переписке, в т.ч. в деловой, особенно если дела связаны с ИТ.
Используй прямой смысловой перевод: временное решение.
Не прямой, ибо workaround не обязан быть временным. Особенно когда workaround’ит чужое приложение.
«Работа не волк, работа — ворк, а волк — гулять.»
Не прямой, ибо workaround не обязан быть временным. Особенно когда workaround’ит чужое приложение.
Так ведь нет ничего более постоянного, чем временное.
А если серьёзно, то надо тогда разделять два понятия, которые в английском языке называются одним словом.
Если workaround применяется ввиду ошибки, пусть и в чужом приложении, вполне можно сказать «временное решение».
А в ситуации «an application we use outputs data in one format and we need it in another format, so here’s a workaround for that», можно сказать просто «решение». Или подходящее к ситуации понятие, например, «конвертер».
Я что-то пропустил и байпас уже стал русским словом? По теме: с контекстом было бы понятнее